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Introdugao 

Os estudos sobre a produgao de conhecimen- 
to - sejam eles da area de sociologia, economia, ad- 
ministragao ou mesmo filosofia — reconhecem, em 
geral, a validade da ideia de que existem diferentes 
regimes ou sistemas de produgao do conhecimento — 
aos quais correspondem formas especfficas de estru- 
tura organizacional, organ izagao do trabalho, regi- 
me de recompensa, motivagao subjetiva, praticas e 
valores sociais, e formas de gestao da propriedade 
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intelectual (Merton, 1957, 1963, 1973; Bourdieu, 
2004; Biaglioli, 1998; Nelson, 2004; Shinn, 2000a 
e b, 2008b). 

Existem muitas possibilidades de classificagao 
dos regimes de produgao de conhecimento, depen- 
dendo da enfase que se de as diferentes dimensoes 
que os caracterizam. Assim, a primeira hipotese do 
presente trabalho e a de que existem dois regimes 
sob os quais se organizou, historicamente, a ativi- 
dade de desenvolvimento de software : um regime 
publico/cientifico e um regime privado/empresarial } 
Esta compreensao - de que existem dois regimes 
distintos para a produgao de software - e cada vez 
mais comum na literatura sobre o tema (Gambar- 
della e Hall, 2006; Laat, 2005; Bonaccorsi e Rossi, 
2005, Osterloch e Rota, 2007). O que nao e tao 
comum, e se configura, portanto, como a contri- 

buiqao mais original deste artigo e, de um lado, a 

abordagem historica da configuraqao desses dois re- 

gimes e, de outro, a analise dos fatores que determi- 
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nam o sucesso tecnico e “comercial” de um regime 
em derrimenro do outro. 

Assim, trabalhamos com duas hipoteses com- 
plementares: a primeira, de que o desenvolvimen- 
to do software livre pertence historicamente ao 

regime publico/cientifico de produqao do conhe- 

cimento , ou seja, o software livre mimetiza a or- 
ganiza^ao da “comunidade” cientifica porque tem 
nela as suas raizes historicas; e a segunda, de que 
em uma “competiqao de mercado” o regime publi- 

co/cientifico se mostrou mais eficiente e, por isso, 

obrigou as empresas que trabalhavam no regime 

privado / empresarial a adotar o software livre ou de 

codigo aberto . 

A colaboraqao pre-competitiva 

O PACT I e II 

Ha um consenso mais ou menos difundido en- 
tre os principals estudiosos do software livre e/ou de 
codigo aberto de que as praticas colaborativas para 
o desenvolvimento de softwares sao anteriores ao 
projeto GNU e a cria$ao da Free Software Founda- 
tion (Raymond, 2000; Weber, 2004; Kim, 2005). 
Segundo Raymond: 

[...] a FSF [Free Software Foundation] nunca 
foi a unica iniciativa na area. Sempre existiu 
uma forqa mais silenciosa, menos confronta- 
dora e mais amigavel em rela^ao ao mercado 
na cultura hacker. Os “pragmaticos” foram le- 
ais menos a uma ideologia do que a um con- 
junto de tradigoes de engenharia fundado nos 
primeiros esforqos do codigo aberto que pre- 
cederam a FSF. Essas tradigoes incluem, mais 
notadamente, as culturas interligadas do Unix 
e da Internet pre-comercial (2000, p. 2). 

De fato, nao e diflcil perceber - analisando a 

historia das praticas de desenvolvimento de softwa- 

re - que a colaboraqao parece ser tao antiga quanto 
o proprio software em si . Quando, no comego da 
decada de 1950, surgiram os primeiros computa- 
dores comerciais - por exemplo, o 701 da IBM 
langado em 1952 a um custo de manutengao men- 


sal de U$ 15,000 -, a necessidade de desenvolver 
programas que os fizessem funcionar era tao grande 
quanto a dificuldade tecnica envolvida nessa ativi- 
dade. Tambem era um fator importante a escassez 
de mao de obra capaz de levar a cabo a tarefa 2 e a 
inexistencia de um mercado bem desenvolvido para 
esse tipo de produto. Neste contexto - de imensa 
necessidade de um rapido processo de desenvolvi- 

mento tecnologico e de um alto custo e risco envol- 
vido na sua realizagao -, o processo de escrita das 

primeiras linhas de codigo acabou fortalecendo um 

ambiente favoravel as praticas de colaboragao. 

O acontecimento que marcou, historicamente, 
a consol idagao de praticas colaborativas nos pro- 
cessos de desenvolvimento de software foi a criagao 

do Project For Advancement of Coding Techni- 

ques (PACT) em 1952, O PACT envolvia diver- 
sas empresas da area de informatica 3 num esforgo 
cooperative para o desenvolvimento de um sistema 
operacional 4 automatico para o IBM 701. O pro- 
jeto teve duas edigoes - os assim chamados PACT- 
-I e PACT-II - cujo resultado final foi o primeiro 
software desenvolvido de forma colaborativa por 
empregados de firmas diferentes (Bernstein, 1973), 
um esforgo denominado, modernamente, de pes- 
quisa pre-competitiva. 

Por ser o primeiro projeto colaborativo de 

maior relevancia que se conhece, o PACT e consi- 

derado, por alguns autores, um marco fundamen- 

tal no surgimento de uma “cultura da colaboraqao” 
entre programadores de software. Para Eric E. Kim, 
por exemplo, e possivel dizer que antes do PACT a 
cultura da colaboraqao, condi^ao necessaria para o 
surgimento de projetos colaborativos, simplesmen- 
te nao existia (Kim, 2005). 5 

A nossa hipotese, neste artigo, e um pouco di- 
ferente da de autores como Kim e outros que atri- 
buem o surgimento da cultura de colaboraqao entre 
programadores de software a projetos especificos de 
sistemas operacionais como o PACT ou mesmo ao 
BSD/Unix. Da nossa perspectiva, a cultura da co- 
laboraqao esta ligada, antes, a tradiqao academico/ 

cientifica na qual esses programadores se forma- 

ram. Outros autores (Raymond, 1999; Bonaccorsi 
e Rossi, 2003; DiBona et al., 1999) tambem ressal- 
tam as origens academico-cientificas da comunida- 
de hacker. 
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A comunidade de programadores e muito he- 
terogenea, mas a explicaqao para o enorme re- 
sultado alcanqado pelo projeto do codigo aber- 
to reside na cultura hacker dos “programadores 
reais” vindos dos campos da fisica e das enge- 
nharias no pos-guerra. [...] muitas geraqoes de 
cientistas da computaqao foram formados no 
mundo academico e nos centres de pesquisa 
das grandes corporaqoes de software (Bonac- 
corsi e Rossi, 2003, p. 1245). 

Mas independentemente do fato de o PACT 
nao ter “originado” a cultura de colaboraqao entre 
programadores de software, o projeto acabou se tor- 
nando um marco do sucesso dessa forma colabora- 
tiva de produqao de software, de tal modo que ela 
passou a ser considerada a “forma ideal” da ativi- 
dade de desenvolvimento e programaqao. Segundo 
Paul Armer, um dos programadores envolvidos no 
PACT- 1: 

O esplrito de cooperaqao entre as organiza- 
qoes participantes e seus representantes du- 
rante a formulaqao do PACT-I foi um dos re- 
cursos mais valiosos que surgiu do projeto. E 
essencial que esse esplrito de cooperaqao con- 
tinue nos pianos de projetos futuros (Armer, 
1973, s/p). 

Embora acreditemos que o PACT nao seja 
a raiz principal da colaboraqao incorporada pelo 
software livre, ele certamente contribuiu para 
consolidar a cultura de colaboraqao que tinha 
origem nas praticas cientlficas. No campo do sof- 
tware, esse ethos colaborativo se expressou de ma- 
neira mais clara e m duas experiencias : o projeto 
BSD, que se desenvolveu em torno da Universi- 

dade da California, e o projeto GNU, a partir do 

MIT Na experiencia californiana, a ausencia de 
uma polltica de licenciamento de direitos auto- 
rais levou a uma incorporaqao pelo mercado que 
introduziu praticas competitivas e fragmentou o 
codigo; ja no projeto GNU, a liqao do BSD foi 
incorporada e uma inovadora estrategia de licen- 
ciamento foi desenvolvida para conter a disper- 
sao competitiva e garantir a sustentabilidade da 
colaboraqao. 


O projeto BSD/Unix 

A possibilidade de que os projetos para o de- 
senvolvimento de softwares permanecessem no am- 
bito dos esforqos colaborativos - ou, dito de outre 
modo, no ambito do regime publico/cientlfico de 
produqao do conhecimento - foi assegurada, al- 
guns anos mais tarde, pelo acordo firmado entre o 
governo dos Estados Unidos e as grandes empre- 
sas da area de telefonia da epoca: AT &T e Western 
Eletric Company Inc. 

Desde janeiro de 1949, o governo norte-ame- 
ricano, atraves da Divisao Antitruste do Departa- 
mento de Justiqa, movia uma aqao contra a AT&T 
e a Western Eletric Company Inc. pela violaqao da 
Lei Sherman - o famoso dispositivo norte-ameri- 
cano antitrustes e contra a propriedade cruzada de 
1890. O processo, que durou mais de sete anos, 
terminou em 1956, com a deliberaqao do juiz Tho- 
mas F. Meaney, por meio de um consent decree, 6 se- 
gundo o qual as empresas envolvidas se comprome- 
tiam a nao desenvolver atividades comerciais fora 
da area de telegrama e telefonia: “A acusada AT&T 
e forgada e impedida de se engajar, direta ou indire- 
tamente (por intermedio de suas subsidiarias outras 
que nao a Western e suas subsidiarias) em qualquer 
negocio que nao seja o fornecimento de serviqos de 
comunicaqao” (United States District Court, 1956, 
s/p). Mais do que isso, a deliberaqao de Meaney, 
e a interpretaqao que dela tiveram os advogados 
das duas empresas envolvidas, implicou uma de- 
terminaqao de que todas as patentes da AT &T, da 
Western Eletric e de suas subsidiarias fossem licen- 
ciadas a custos nominais e sem maiores restriqoes 
(Sal us, 1994, p. 57). Como os Bell Telephone Labs, 
mais conhecidos como Bell Labs, eram, nessa epo- 
ca, subsidiaries tanto da AT &T como da Western 
Eletric - cada uma possuia 50% dos laboratories -, 
eles tambem ficaram obrigados a licenciar todas as 
suas patentes considerando as determinaqoes do 
consent decree: ou seja, a um custo mmimo e sem 
restriqoes significativas. 

Segundo Sal us (1994), o Consent Decree de 
1956 e a interpretaqao conservadora dada a ele 
pelos advogados da AT&T e da Western Eletric, 
tiveram, juntos, um efeito decisivo para a politi- 
ca relativa as pesquisas que os Bell Labs viriam a 
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desenvolver na area de software e programa$ao em 
geral. Por nao serem passfveis de comercializaqao 
- dado que eram consideradas, na epoca, externas 
as areas de telegrama e telefonia, as quais deveriam 
se restringir as operaqoes da AT&T e da Western 
Eletric essas pesquisas puderam se desenvolver, 
nos laboratories, com certa liberdade e forte carater 
colaborativo. 

Assim, em 1964, os Bell Labs comecaram a de- 

senvolver um sistema operacional chamado Multics 
(Multiplexed Information and Computing Service) 

em parceria com o MIT e com a General Eletric, 

dentro desse registro colaborativo que marcava as 

pesquisas do laboratorio na area . No entanto, em 
1969, depois de cinco anos de pesquisas, o projeto 
foi abandonado pelos Bell Labs por razoes conside- 
radas, na epoca, de ordem “tecnica”. A decisao de 
abandonar o Multics, no entanto, foi antes da dire- 
$ao dos laboratories do que dos pesquisadores en- 
volvidos no projeto. Entre esses, Ken Thompson e 
Dennis Ritchie, em especial, estavam convencidos 
das potencialidades do Multics e se empenharam - 
a principio, fora do ambito da empresa 7 - no proje- 
to de um sistema operacional inspirado no Multics 
(Weber, 2004). 

Em outubro de 1973, na quarta ediqao do 

Symposium on Operating Systems Principles, 8 

ocorrido na Purdue University de Nova York, 

Thompson e Ritchie inscreveram um artigo que 

apresentava para a comunidade de programadores e 

pesquisadores de software, as possibilidades de “uso 

e implementaqao” do Unix, um “sistema operacio- 

nal de proposito geral, multiusuario e interativo 
para o DEC/PDP —1 1/40” (Thompson e Ritchie, 
1973, p. 1). 

O fato de o Unix ter sido apresentado original- 
mente em um congresso academico mostra o quan- 
to os Bell Labs, apesar de serem um conjunto pri- 
vado de laboratories, valorizavam a relaqao com a 
academia, sobretudo a norte-americana . Essa valo- 
rizacao do mundo academico refletia-se claramente 

na sua propria organizaqao interna, que mimetiza- 
va, em muitos aspectos, a organizaqao academica de 

produqao do conhecimento . 

O Unix, apresentado no Symposium on Ope- 
rating Systems Principles em 1973, despertou a 
atenqao dos pesquisadores universitarios imediata- 


mente, de modo que, ja em 1975, mais de qua- 
renta universidades norte-americanas possuiam 
computadores que rodavam Unix (Salus, 1994). A 
rapida difusao do Unix foi possibilitada, em grande 

medida, pela politica de licenciamento de software 

da AT&T. Como vimos, uma vez que a empresa 
nao podia explorar comercialmente “ softwares para 

computador”, nem aferir royalties do seu patente- 

amento por conta das limitaqoes instituidas pelo 

Consent Decree de 1956, a soluqao foi licenciar sof- 

twares como o Unix apenas para fins de pesquisa, 
a custos nominais, mas sem nenhum servico de 

suporte ou manutenqao, ou seja, sem onus para a 

empresa. Essa politica de licenciamento teve um 

efeito duplo e complementar: por conta do seu bai- 

xo custo, o Unix disseminou-se rapidamente entre 

instituiqoes de pesquisa e universidades. Paralela- 
mente, a ausencia de qualquer serviqo de suporte 
ou manutengao obrigou a comunidade de usuarios 
de Unix a compartilhar informa^oes, solu^oes de 
problemas e atualizagoes do sistema. 

Entre os usuarios mais interessados no siste- 
ma, estava o pesquisador Robert Fabry do Depar- 
tamento de Ciencia da Computa^ao, Estatistica 
e Matematica da Universidade de Berkeley, Cali- 
fornia. Fabry assistiu a apresentaqao de Ritchie e 
Thompson no simposio de Nova York, em 1973, 
e passou a acompanhar o trabalho deles para fins 
de pesquisa. O interesse cientifico de Berkeley e 
o desinteresse comercial dos Bell Labs no Unix 
possibilitaram um longo processo de colabora$ao 
entre as duas instituiqoes. 

Esse processo intensificou-se a partir de 1978, 
quando os pesquisadores de Berkeley colocam, em 
um mesmo “pacote de distribuigao”, o kernel 9 do 
Unix e outros softwares, formatando uma linha de 
distribui$ao do Unix que ficou conhecida como 
BSD, ou Berkeley Software Distribution. No ano 
seguinte, Robert Fabry propos oficialmente ao Dar- 
pa - Defense Advanced Research Projects Agency - 
um projeto de desenvolvimento de uma versao do 
BSD - com o kernel do Unix - para a Internet. O 
projeto foi aprovado em 1980, originando o Com- 
puter System Research Group, ligado ao Depar- 
tamento de Ciencia da Computaqao de Berkeley. 
O grupo desenvolveu, nos dezoito meses previstos 
para o projeto, uma versao do BSD integrada a 
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Internet, tambem conhecida como a 4 a versao da 
BSD/Unix. 

Mas esse processo de relativa liberdade e in- 

tensa colaboragao inter-institucional passou a en- 

frentar algumas dificuldades a partir do final dos 

anos de 1970, quando a incipiente popularizagao 

do computador pessoal possibilitou o surgimento 

de um mercado de software , levando as empresas a 

iniciarem politicas mais agressivas de protegao e dis- 

tribuigao dos seus produtos. O documento para- 
digmatico dessa mudanga de atitude das empresas 
e a carta do jovem fundador da Microsoft aos “en- 
tusiastas” nao profissionais que animavam o hoje 
lendario Homebrew Computer Club, um forum de 
“amadores” interessados em microcomputadores e 
que se reunia na Universidade de Stanford, entre 
1975 e 1977, para compartilhar diferentes versoes 
de programas de computador. A carta, assinada por 
Bill Gates, reclamava do compartilhamento de um 
software, o Altair-Basic, que a Microsoft havia de- 
senvolvido para o primeiro microcomputador pes- 
soal, o Altair 8800: 

Como a maioria dos amadores deve saber, a 

maior parte de voces rouba os seus softwares. 

O hardware precisa ser comprado, mas [para 

voces] o software deveria ser compartilhado. 

Quern se importa se as pessoas que trabalha- 

ram nele serao pagas? Isso e justo? [...] O que 

voces fazem e impedir que software de qua- 

lidade seja escrito. Quern pode bancar fazer 

trabalho profissional por nada? Que amador 

pode despender tres anos-trabalho em progra- 

magao, encontrar todos os bugs, documentar 

o trabalho e distribui-lo de graga? O fato e 

que ninguem, com a excegao de nos, inves- 

tiu tanto dinheiro no software para amado- 

res Nos esrrevemos o Basic 0800 e estamos 
escrevendo o APL 8080 e o APL 6800. mas 

ha muito pouco incentivo para tornar esse 

software disponivel para os amadores. Falando 

francamente, o que voces estao fazendo e rou- 

bo (Gates, 1976, p. 2) 

Essa mudanga na forma como o comparti- 
lhamento de software passou a ser visto a partir do 
surgimento de um mercado especifico de progra- 


mas de computador ecoou tambem na AT&T. A 
empresa, que desde 1974 estava sendo novamente 
processada pelo governo norte-americano por mo- 
nopolio, foi obrigada, em 1982, a se separar tan- 
to dos Bell Labs como da Western Electric. Essas 
mudangas de natureza politica e economica fizeram 
com que, a partir de 1983, a AT&T internalizasse o 
desenvolvimento do Unix, criando o Unix System 
Labs e alterando radicalmente a forma de distribui- 
gao e licenciamento do software. Por conta disso, 
em 1988, a licenga do Unix ja custava aproximada- 
mente U$ 100 mil chegando, alguns anos depois, 
a U$250 mil (Weber, 2004, p. 39). A mudanga da 
politica de licenciamento do Unix resultou no pau- 
latino arrefecimento da colaboragao entre os Bell 
Labs e a Universidade de Berkeley, que culminou 
no processo judicial movido pela AT&T contra a 
universidade californiana em 1 992. 

O enfraquecimento das redes de colaboragao 
entre Berkeley - que tinha a sua distribuigao pro- 
pria do Unix, a BSD - e a AT&T - que tambem 
mantinha a sua versao de distribuigao - comegou, 
no entanto, antes mesmo da mudanga da politica 
de licenciamento da empresa. Ja em 1981, aAT&T 
proibiu a Universidade de langar a versao 4.1 da 
Berkeley Software Distribution (BSD) porque pre- 
tendia, ainda naquele ano, langar a sua distribuigao 
comercialmente. 

Assim. a historia do Unix na decada de 1980 

e marcada, de um lado, pela ruptura das relagoes 

colaborativas que pautaram o seu desenvolvimen- 

to em um contexto em que o mercado de software 
era pouco desenvolvido e que uma das principals 

empresas envolvidas nesse processo nao podia ex- 

plorar os resultados dessas pesquisas comercial- 

mente; de outro, pela completa fragmentagao do 
processo de desenvolvimento do Unix. 

A historia da fragmentagao do projeto Unix 
e o seu consequente fracasso na decada de 1980, 
bem como a ascensao do projeto GNU - cuja si- 
gla significa, justamente, “GNU Nao e Unix” - nos 
anos 1 990 sao processos incompreensiveis sem uma 
analise da politica de licenciamento da Berkeley 
University. A licenga BSD e considerada uma das 
mais liberals que existem porque permite, grosso 
modo, qualquer tipo de utilizagao sem imposigao 
de nenhuma exigencia especifica sobre o carater dos 
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futures licenciamentos derivados. 10 Os term os da 
licenga ate 1 994 diziam o seguinte: 

A redistribuigao e o uso em codigo-fonte ou 
binario, com ou sem modificagao, e permitida 
desde que as seguintes condigoes sejam segui- 
das: 1. Redistribuigoes do codigo-fonte devem 
conter a nota de copyright acima, esta lista de 
conduces e as restrigoes que se seguem; 2. Re- 
distributes em forma binaria devem repro- 
duzir a nota de copyright acima, esta lista de 
condigoes e as restrigoes que se seguem na sua 
documentagao e/ou em outre material ofere- 
cido com a distribuigao; 3. Todo material de 
propaganda que mencione vantagens ou uso 
desse software deve conter o seguinte agradeci- 
mento: Este produto inclui software desenvol- 
vido pela Universidade da California, Berkeley, 
e seus contribuidores. 4. Nem o nome da Uni- 
versidade nem os seus contribuidores podem 
ser usados para endossar ou promover produ- 
tos derivados desse software sem a permissao 
previa e especifica (BSD License, s/d). 11 

Essa forma especifica de licenciamento - sem 
qualquer exigencia ou prescrigao quanto a forma 
de distribuigao dos softwares derivados - pode 
ser interpretada, grosso modo, como uma nao-li- 
cenga. Na medida em que abre possibilidade para 
que versoes e modificagoes feitas em um software 
sejam posteriormente distribuidas sob uma licenga 
restritiva, ou seja, sem a obrigagao de publicizagao 
do codigo-fonte, a licenga BSD implicou, concre- 
tamente, o fim de ciclos de desenvolvimento cola- 
borativos. Em outras palavras, a licenga de Berke- 
ley nao garantiu - ao contrario da General Public 
Licence, que seria desenvolvida anos depois - que 
todas as modificagoes feitas sobre o software licen- 
ciado permanecessem “publicas”, abrindo caminho 
para a criagao de obras derivadas proprietarias. Essa 
caracteristica da Licenga BSD determinou que os 
diferentes projetos derivados do Unix se fragmen- 
tassem, uma vez que deu origem a projetos comer- 
ciais que passaram a concorrer fortemente entre si. 

Nesse registro, a AT&T manteve a sua dis- 
tribuigao do Unix, mas com uma politica de li- 
cenciamento alterada a partir de 1983, quando a 


distribuigao do software passou a ser cobrada. A 
Universidade de Berkeley, por sua vez, continuou 
com a sua distribuigao propria ate 1989, quando 
em um esforgo coordenado pela universidade, a 
comunidade de usuarios do BSD-Unix reescreveu, 
por engenharia reversa, partes inteiras do programa 
que era, entao, disputado pela AT&T. Esse projeto 
resultou no Networking Release 1 - uma nova dis- 
tribuigao do Unix. 12 Paralelamente, inumeras em- 
presas - como, por exemplo, a LIP, a IBM, a Sun 
Microsystem, entre outras - comegaram a desen- 
volver versoes proprias do sistema. Desse modo, no 
infcio dos anos de 1990, o Unix era distribuido em 
inumeras versoes concorrentes e, muitas vezes, in- 
compativeis entre si. 

A ruptura das relagoes de colaboragao entre 
Berkeley e a AT&T e o surgimento de versoes pro- 
prietarias do Unix explicam-se, sobretudo, como 
dissemos, pelo fortalecimento do mercado de sof- 
tware, impulsionado pelo surgimento do computa- 
dor pessoal. Essa mudanga, associada a outras como 
o sucesso comercial da Microsoft, marca a transi- 

gao da produgao de software de um regime publico/ 

cientlfico - caracterizado, entre outras coisas, pelo 

compartilhamento de informagoes, em especial do 

codigo-fonte do software - para um regime privado / 

empresarial - no qual a venda do software e a pro- 

tegao do codigo-fonte, via propriedade intelectual, 

desempenham papel central. 

A reagao da comunidade hacker 

O projeto GNU 

Em 1971, o Massachusetts Institute of Tech- 
nology (MIT) contratou Richard Stallman, entao 
um jovem estudante de Harvard, como programa- 
dor do seu Laboratorio de Inteligencia Artificial. 
Stallman tinha trabalhado no laboratorio cientifico 
da IBM, em Nova York, apos concluir o secundario 
e, em Harvard, perseguia seus interesses em Bio- 
logia e Fisica enquanto trabalhava no laboratorio 
do MIT. Durante esses anos. tomou contato com 
a assim chamada “cultura hacker ”, uma subcultura 

muito particular, forjada pel os primeiros programa- 

dores do MIT nos anos de I960 e que se baseava 
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em valores tais como a defesa da democratizacao do 

acesso aos computadores, a crenqa de que a infor- 

macao deveria circular livremente, a desconfianga 

da autoridade baseada em credenciais. a defesa da 

meritocracia pradcamente comprovada e a descen- 

tralizaqao organizacional (Levy, 1984). Alguns des- 
ses valores, como a colaboragao e a publicidade da 
informagao, eram muito proximos do que era, en- 
tao, chamado de ethos cientifico e, provavelmente, 
dnham sido incorporados a cultura hacker a partir 
da pratica cientifica e universitaria do MIT e de ou- 
tras instituigoes de ensino e pesquisa. Nas palavras 
de Stallman: 


Quando comecei a trabalhar do Laboratorio de 
Inteligencia Artificial do MIT, em 1971, inte- 
grei uma comunidade de compartilhamento de 
software que ja existia ha muitos anos. O com- 
partilhamento de software nao era particular- 
mente restrito a nossa comunidade [no MIT]; 
ele nasceu com os computadores, assim como 
o compartilhamento de receitas nasceu com o 
ato de cozinhar (Stallman, 1999). 


Essa “cultura hacker ”, que em termos de valo- 
res gerais podia ser encontrada tambem em outras 
instituigoes como Stanford e Berkeley, sofreu um 
grande impacto a partir da emergencia de um mer- 
cado autonomo de software. 

Stallman costuma aludir a um evento que Ihe 
serviu como uma especie de “revelagao” das mu- 
dangas que afetava a cultura dos programadores 
quando o software passou a ser visto como uma 
atividade comercial que deveria ser exercida de 
forma concorrencial e, portanto, produzido num 
regime outro que nao o publico/cientifico, que 
marcara o desenvolvimento do software ate ali. 
O evento e o “mftico” episodio no qual a Xerox 

se nega a fornecer o codigo-fonte do software da 

impressora laser 9700 para Stallman. Em 1980, 

a impressora que era utilizada no laboratorio do 

MIT comeqou a apresentar problemas no geren- 

ciamento de trabalhos pela rede e Stallman bus- 

cou, sem sucesso, o codigo-fonte do software para 

poder conserta-lo, como ja havia feito antes, no 

registro colaborativo que marcava, entao, a pes- 

quisa na universidade. 


Foi devido a essa filosofia do dar e receber que, 
quando Stallman se deparou com o defeito na 
impressora a laser da Xerox, ele nao entrou em 
panico. Ele simplesmente procurou uma forma 
de atualizar o conserto antigo [que tinha de- 
senvolvido para um modelo anterior] ou entao 
hackear o novo sistema. Ao procurar o software 
da impressora, no entanto, Stallman fez uma 
descoberta perturbadora. A impressora nao ti- 
nha um software, pelo menos nao um que ele 
ou outro programador pudessem ler (Willia- 
ms, 2002). 

Quando as empresas comegaram a comer- 
cializar e, consequentemente, proteger os seus 
softwares, elas deixaram de distribuir o codigo de 
programagao aos usuarios, disponibilizando ape- 
nas o codigo binario que era lido e executado pela 
maquina. Assim, quern comprava o programa 
nao tinha mais acesso ao codigo no qual ele havia 
sido programado (o codigo-fonte), o que dificul- 
tava que o programa fosse imitado por empresas 
concorrentes. O efeito colateral desta estrategia 
de proteger o patrimonio intelectual das empresas 
por meio do sigilo era que o software nao podia 
mais ser desenvolvido - e incrementado - colabo- 
rativamente, ja que as companhias estavam com- 
petindo entre si. 

Nos anos seguintes, esse processo de comercia- 
lizagao intensificou-se ainda mais e o laboratorio 
de Inteligencia Artificial do MIT viu seus melhores 
programadores serem contratados pelo mercado, em 
particular por uma nova empresa chamada Sym- 
bolics. Stallman se viu no dificil dilema de aceitar 
o processo inexoravel de competigao comercial, 
indo trabalhar para alguma empresa, ou abando- 
nar a computagao. Foi em meio a essa duvida em 
relagao a sua trajetoria que Stallman teve a ideia 
ousada de desenvolver um sistema operacional in- 
teiro baseado nos valores de colaboragao dos pri- 
meiros hackers. Seu projeto era criar um “mundo 
paralelo” de liberdade e colaboragao que estivesse 
na contramao das praticas competitivas das empre- 
sas. Ele chamou esse projeto de GNU, um acro- 
nimo recursivo cujo significado era “GNU Nao e 

Unix”, ja que o sistema teria algumas caracteristicas 

do sistema operacional Unix, mas nao seria Unix. 13 
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Em setembro de 1983, ele lan^ou um chamado a 
comunidade hacker pedindo a colabora^ao e, em 
1985, lan$ou um manifesto que apresentava a filo- 
sofia do projeto: 

Eu considero uma regra sagrada a exigencia de 
que eu compartilhe os programas de que gosto 
com outras pessoas que tambem gostem deles. 
Vendedores de software querem dividir os usu- 
arios para conquista-los, fazendo com que cada 
usuario nao compartilhe com os outros. Eu me 
recuso a romper a solidariedade com os outros 
usuarios desta maneira. Eu nao posso, em sa 
consciencia, assinar um contrato com clausula 
de sigilo ou uma licenqa de software. [...] As- 
sim, para continuar a utilizar computadores 
sem desonra, eu decidi elaborar um conjunto 
de softwares livres, de forma que eu consiga 
utiliza-los sem qualquer recurso a software nao 
livre. Eu me demiti do Laboratorio de Inteli- 
gencia Artificial do MIT para nao permitir 
que o MIT tenha qualquer pretexto legal para 
impedir que eu distribua o GNU (Stallman, 
2002, s/p). 

O projeto GNU fazia um apelo moral para 
resgatar o “ato fundamental de amizade entre os 
programadores”, que consistia no “compartilha- 
mento de software” . As novas praticas comerciais 
das empresas, que enfatizavam o sigilo e a compe- 
tiqao, tornavam “fora da lei” a a$ao moral da ami- 
zade e da colaboraqao comunitaria e era preciso, 
portanto, resgata-la, conciliando a “hospitalidade” 
e a “obediencia da lei” (Idem, s/p). A forma pela 
qual se efetivava essa conciliaqao do principio mo- 

ral e da lei era uma licenqa de software “publica”, 
que foi chamada de Licenqa Publica Geral (Ge- 

neral Public License ou GPL) . A GPL foi desen- 
volvida para licenciar os primeiros softwares livres 
que estavam substituindo os softwares proprieta- 
ries. Era uma licen$a que subvertia o proposito 
original do direito autoral, de restringir a copia 
para garantir a remuneraqao do detentor do di- 
reito. Como o titular original do direito autoral 
e “soberano” para estabelecer as condiqoes de uso 
de suas obras, a GPL simplesmente afirmava que, 
no exercicio desse direito, o detentor autorizava o 


livre uso, a modificaqao e a copia do programa na 
forma original ou modificada, desde que essa copia 
mantivesse as liberdades originais: 

Os contratos de licenqa da maioria das em- 
presas de software tentam manter os usuarios 
a merce dessas empresas. Contra isso, nossa 
Licenqa Publica Geral tem o objetivo de garan- 
tir sua liberdade de compartilhar e modificar 
software livre - garantir que o software seja livre 
para todos os usuarios. [...] Em particular, a Li- 
cen$a Publica Geral foi concebida para garan- 
tir que voce tenha a liberdade de dar ou vender 
copias de software livre, que receba o codigo- 
-fonte ou tenha acesso a ele se quiser, que pos- 
sa modificar o software ou usar partes dele em 
novos programas livres e que voce saiba que 
pode fazer essas coisas. Para proteger seus di- 
reitos, precisamos criar restri$oes que proibem 
alguem de negar esses direitos ou de pedir que 
voce entregue os direitos (Idem, s/p). 

O licenciamento da GPL diferia de estrategias 

anteriores de autorizar copias e modificaqoes (por 

exemplo, colocando as obras em dommio publico) 

por exigir que versoes subsequentes mantivessem as 

liberdades de modificar e copiar. Sem esse carater 

“viral”, o codigo liberado poderia ser reapropriado 

por empresas e fragmentado num processo compe- 

titivo subsequente, como tinha acontecido com a 

BSD . Stallman chamou esse efeito viral de copyleft, 
incorporando um trocadilho que havia sido sugeri- 
do por um amigo — Don Elopkins — em 1984 ou 
1985. 14 O copyleft - que e a grande inova^ao con- 
ceitual da licen^a GPL - buscava evitar as apropria- 
qoes de codigo que Stallman havia testemunhado, 
entre elas, uma experiencia propria relativa a uma 
versao de um editor de textos que ele havia origi- 
nalmente desenvolvido no MIT em 1976. O edi- 
tor, chamado Emacs, tinha sido elaborado para o 
sistema operacional ITS (utilizado no laboratorio 
do MIT) e depois fora reescrito para funcionar no 
Unix por James Gosling em 1981. Gosling tinha 
distribuido o codigo do programa livremente bus- 
cando colaboragao, mas depois o vendeu para uma 
empresa chamada UniPress que impediu a sua dis- 
tribuRao livre a partir de entao. 
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No verao daquele ano, cerca de dois anos 
atras [1984], um amigo me disse que devido 
a sua colaboraqao no desenvolvimento inicial 
do Gosling Emacs, tinha recebido permissao 
do Gosling, numa mensagem, para distribuir 
a sua versao do programa. Gosling tinha ela- 
borado seu Emacs e distribuido de forma li- 
vre, conseguindo que muita gente colaborasse 
com ele no desenvolvimento, na expectativa, 
segundo o proprio Gosling diz no manual, 
de que seguiria com o mesmo espirito com o 
qual eu havia lan^ado o Emacs original. En- 
tao, ele deu uma facada pelas costas em todo 
mundo, colocando direitos autorais no pro- 
grama, fazendo as pessoas prometerem nao 
distribuf-lo e vendendo o software para uma 
empresa. [...] Neste ponto, a companhia para 
a qual Gosling tinha vendido o programa 
contestou o direito de meu amigo distribui-lo 
e a mensagem [onde Gosling o autorizava a 
faze-lo] estava armazenada em fitas de backup 
que ele nao conseguia encontrar. E Gosling 
negou que tivesse dado permissao a ele (Stall- 
man, 1986). 

Com o copyleft , no entanto, esse tipo de ma- 
nobra proprietaria nao era mais possivel. A licenga 
GPL garantia em termos legais solidos que a obra 

podia ser modificada e redistribuida, e o carater vi- 

ral do copyleft fazia com que copias ou obras deriva- 
das adotassem compulsoriamente a mesma licenqa, 

difundindo as liberdades presentes na licenqa ori- 

ginal . Foi sem duvida devido ao carater viral des- 
sa forma de licenciamento que o projeto GNU 
conseguiu se expandir rapidamente nos anos se- 
guintes. Com programas de excelente qualidade 
tecnica, quase sempre distribuidos gratuitamente 
e acompanhados do codigo-fonte, muitos pro- 
gramadores, tanto do meio academico como em- 
presarial, passaram a fazer uso desse patrimonio 
“publico” para produzir novos programas, mais 
complexos. E ao construir ferramentas baseadas 
em outras ferramentas licenciadas sob a GPL, 
terminavam inserindo essas obras derivadas no 
fundo publico comum compulsoriamente. O 
crescimento do software livre assumia, assim, uma 
velocidade exponencial. 


O Linux 

No final dos anos de 1980, o projeto de criar 
programas “livres” que substituissem os “proprie- 
taries” constituindo, assim, um sistema opera- 
cional completo estava proximo do fim. Falta- 
va apenas um kernel, a parte central do sistema 
operacional encarregada da comunica^ao entre o 
software e o hardware. Enquanto a Free Software 
Foundation de Stallman se dedicava a um com- 
plexo projeto de kernel chamado Elurd, um estu- 
dante de pos-gradua$ao da Finlandia, Linus Tor- 
valds, anunciava o desenvolvimento de um kernel 
simples, mas eficiente, inspirado em um kernel aca- 
demico chamado Minix, que havia sido desen- 
volvido por Andrew Tanenbaum na Universida- 
de Vrije de Amsterda. Em 25 de agosto de 1991, 
Torvalds enviou uma mensagem para o grupo de 
Usenet comp. os. minix anunciando o projeto do 
Linux e, no mes seguinte, lan$ou a primeira ver- 
sao do kernel (versao 0.01) com a seguinte nota 
de copyright-. 

Este kernel e ©1991 Linus Torvalds, mas ele 
pode, no todo ou em partes, ser redistribuido 
desde que voce faqa o seguinte: 

- Todo o codigo deve ser disponibilizado (li- 
vremente), se nao com a distribui^ao, pelo me- 
nos quando requisitado 

- Notas de copyright devem permanecer in- 
tactas (na verdade, se voce distribuir apenas 
parte dele, voce precisara adicionar copyright, 
uma vez que nao ha ©s em todos os arquivos). 
Trechos menores podem ser copiados sem dar 
atengao a copyrights. 

- Voce nao pode distribuir exigindo uma taxa, 
nem mesmo para cobrir custos de “envio”. 
Mande-me um email se voce tiver perguntas. 
Infelizmente, um kernel sozinho nao faz nada. 
Para ter um sistema que seja operacional, voce 
precisara de um shell, compiladores, uma bi- 
blioteca etc. Tratam-se de partes separadas e 
que podem estar [licenciadas] sob copyrights 
mais estritos (ou frouxos). A maior parte das 
ferramentas utilizadas com o Linux sao progra- 
mas GNU e estao sob o copyleft GNU. Essas 
ferramentas nao estao na distribui^ao. Para 
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maiores informagoes, me escreva (ou escreva 
para o GNU) (Torvalds, s/d [a]). 

Curiosamente, nessa primeira versao do Linux, 
a licenga nao e livre, pelo menos nao na definigao 
que Stallman havia dado ao termo. Desde o comedo, 
Stallman havia incluido entre as liberdades do softwa- 
re, a de vende-lo. O que tornava um software livre era 
o fato de que ele permitia a colaboragao entre seus 
programadores, garantindo o acesso ao codigo-fonte 
e a livre reprodugao e execugao; e a mercantilizagao 
do software em si, por outro lado, nao se constituia 
em um problema, embora, naqueles primeiros anos, 
se acreditasse que a oferta do codigo-fonte tornava 
inviavel a venda de software livre - o que, depois, se 
mostrou possivel, agregando-se a ele uma marca, por 
exemplo (Young, 1999). Era exatamente por isso 
que Stallman sempre enfatizou que o termo free da 
expressao free software referia-se a liberdade e nao ao 
prego - na formula que ficou consagrada: “To un- 
derstand the concept you should think of free as in 
free speech, not as free beer” (Stallman, 1996). 

Torvalds afirma que a adogao de uma licenga 
que permitia a copia e o acesso ao codigo-fonte era 
parte da tradigao academica de compartilhamento 
de resultados cientificos. Por outro lado, a restrigao 
ao uso comercial vinha do temor de que a introdu- 
gao do Linux no circuito comercial tirasse do autor 
o controle sobre o seu produto e desvirtuasse, con- 
sequentemente, seus objetivos tecnicos: 

Quando, originalmente, publiquei o Linux, 
senti que estava seguindo as pegadas de seculos 
de cientistas e outros academicos que construi- 
ram seu trabalho sobre as fundagoes de outros 
- nos ombros de gigantes, nas palavras de Sir 
Isaac Newton. [...] Creio que teria abordado 
a coisa de modo diferente se nao tivesse sido 
criado na Finlandia, onde qualquer um exibin- 
do o menor sinal de ganancia e visto com sus- 
peita, ou inveja. [...] E sim, eu sem duvida teria 
abordado de maneira diferente a coisa do “sem 
dinheiro” se nao tivesse sido criado sob a in- 
fluencia de um avo resolutamente academico e 
um pai resolutamente comunista. De qualquer 
modo, eu nao queria vender o Linux. E eu nao 
queria perder o controle, o que significa que eu 


nao queria que ninguem o vendesse tambem. 
Eu deixei isso claro na pob'tica de copyright que 
incluf na copia da primeira versao que “subi” 
em setembro. [...] Pense bem. Voce coloca seis 
meses da sua vida nessa coisa e quer torna-la 
dispomvcl e quer tirar algo dela, mas nao quer 
que as pessoas se aproveitem. [...] Fazia senti- 
do para mim que a melhor maneira do Linux 
se desenvolver tecnologicamente era mante-lo 
puro. Se houvesse dinheiro envolvido, as coi- 
sas ficariam obscuras. Se nao ha dinheiro em 
jogo, nao ha pessoas gananciosas (Torvalds e 
Diamond, 2001, pp. 93-94). 

Esta claro que, neste relato, Torvalds demons- 
tra uma diferenga em relagao a Stallman quanto ao 
papel da permissao de uso comercial, referindo-se, 
no fundo, a free como cm free beer (“Voce nao pode 
distribuir cobran do uma taxa”). Em um momento 
posterior, no entanto, devido ao fato de querer uti- 
lizar uma ferramenta licenciada em GPL no Linux 
(o compilador GCC, desenvolvido por Stallman), 
ele e obrigado a adotar a licenga GPL, que nao 
restringe o uso comercial (Torvalds, 1999). Essa 
adogao, alias, mostra de maneira clara o efeito pra- 
tico de uma licenga viral, com copyleft. Na versao 
seguinte do Linux (0.0.12) de fevereiro de 1992, ja 
aparece a seguinte nota: 

O copyright do Linux vai mudar: recebi algu- 
mas solicitagoes para torna-lo compativel com 
o copyleft do GNU, removendo a condigao 
“voce nao pode distribui'-lo por dinheiro”. Eu 
concordo. Proponho que o copyright seja mu- 
dado de forma a conformar-se com o GNU - 
se tiver a aprovagao das pessoas que ajudaram 
a escrever o codigo. Presumo que nao sera 
problema para ninguem: se voce tern queixas 
(“Eu escrevi o codigo presumindo que o copyri- 
ght permaneceria do mesmo modo”) me envie 
uma mensagem. Do contrario, o copyleft do 
GNU tera efeito a partir de primeiro de feve- 
reiro. Se voce nao conhece a essencia do copyri- 
ght do GNU - leia (Torvalds, s/d [b]). 

Assim, no comego dos anos de 1990, o projeto 
GNU havia realizado seu objetivo principal de de- 
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senvolver um sistema operacional completo baseado 
em uma licenga livre (a versao 1.0 do Linux foi lan- 
gada em 1994). Nos anos seguintes, o Linux ganhou 
reputagao como um sistema eficiente e estavel; por 
suas virtudes tecnicas e cooptagao de esforgos por 
meio do copyleft, despertou o interesse e a preocupa- 
gao da comunidade empresarial. 

A incorporagao do regime publico/cientifico 
e os novos modelos de negocios 

As primeiras empresas de software livre, como 
a Cygnus e a VA Research, eram relativamente pe- 
quenas e baseavam-se no unico modelo de negocios 
viavel que se imaginava naqueles primeiros anos 
da decada de 1990: a distribuigao gratuita do sof- 
tware e a venda de servigos. No manifesto GNU, 
de 1985, Stallman ja havia sugerido que os pro- 
gramadores poderiam garantir seus rendimentos 
deslocando a sna fonre de renda do lirenriamenro 

dos direitos autorais para os servigos de instalagao, 

personalizagao e manutengao dos programas : 

A restrigao de copia nao e a unica base para 
os negocios no software. E a base mais comum 
porque e a que traz mais dinheiro. Se fosse 
proibida ou rejeitada pelo cliente, as empresas 
de software teriam que encontrar outras bases 
de organizagao que agora sao pouco explora- 
das. Existem diversas formas de organizar qual- 
quer tipo de negocio. [...] Um fabricante que 
introduza um novo computador podera pagar 
pela transposigao de sistemas operacionais para 
o novo hardware. A venda da atividade de ensi- 
no, orientagao e servigos de manutengao tam- 
bem podem empregar programadores. Pessoas 
com novas ideias poderao distribuir programas 
como freeware, pedindo doagoes de usuarios 
satisfeitos ou vendendo servigos de orientagao. 
Ja conheci pessoas que estao trabalhando desta 
maneira com sucesso. Usuarios com necessida- 
des parecidas poderao formar grupos de usua- 
rios e pagar taxas. Um grupo podera contratar 
empresas de programagao para escrever progra- 
mas que os membros queiram utilizar (Stall- 
man, 2002, s/p). 


Mas o mundo do software livre so sentiu, de 
fato, o impacto do mundo dos negocios quando 
as grandes empresas de tecnologia da informagao 
comegaram a se aproximar daquele modelo de pro- 
dugao — mais ou menos no mesmo momento em 
que as primeiras empresas de software livre come- 
gam um processo de fusao (VA Research unindo- 
-se a empresa Linux ffardware, e a Cygnus a Red 
Elat) e de abertura de capital na bolsa. O primeiro 
precedente significativo do interesse da parte tradi- 

cional do mundo dos negocios pelo software livre 

foi a decisao da Netscape de liberar o codigo do seu 

navegador para impedir a dominagao do mercado 

pela Microsoft, migrando seu modelo de negocios 

totalmente para a oferta de servigos para o setor 

empresarial. 

Com o crescimento da Microsoft no mercado 
de navegadores, a Netscape temia que ela passasse 
a impor padroes de protocolos nao publicos, sabo- 
tando, assim, as suas concorrentes no mercado de 
servidores (que teriam dificuldade para servir pagi- 
nas num padrao privado). A medida que ia domi- 
nando o mercado de navegadores, com o Internet 
Explorer, a Microsoft passava a utilizar uma codifi- 
cagao propria para paginas Web que apenas os seus 
proprios servidores eram capazes de produzir. Dessa 
maneira, ela transpunha a dominagao do mercado 
de navegadores para o mercado de servidores. Para 
impedir, entao, que a Microsoft dominasse o mer- 

cado de navegadores, a Netscape decidiu transferir 
o desenvolvimento do seu programa de navegaqao 

para a comunidade de software livre e, tendo garan- 

tido a concorrencia neste mercado, passou a se con- 

centrar nos servidores, que Ihe eram mais rentaveis . 

Assim, em Janeiro de 1998, a Netscape anunciou 
que passaria a distribuir o codigo do seu programa 
para a comunidade de software livre sob uma licen- 
ga “herdeira” da GPL, passando a se concentrar no 
mercado de “solugoes empresariais”: 

A Netscape migrou com sucesso seu modelo 
de negocios no ano passado em diregao a ven- 
da de softwares empresariais, para rendimen- 
tos ligados ao seu site, afastando-se assim dos 
rendimentos advindos de clientes isolados. No 
terceiro quadrimestre de 1 997, os rendimentos 
advindos destes clientes representavam aproxi- 
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madamente 1 8% da receita da Netscape - todo 
o resto vinha do software empresarial, servigos 
e o site. [...] Juntamente com o seu cliente gra- 
tuito [free] , a Netscape anunciou tambem que 
esta langando um conjunto de produtos e ser- 
vigos aperfeigoados que alavancam seu cliente, 
tornando facil para consumidores individuals e 
empresariais adotarem solugoes Netscape. Os 
novos produtos e servigos reforgam a estrate- 

gia da Netscape de alavancar a penetragao de 

mercado do seu popular cliente e seu concor- 

rido site de Internet para fomentar ainda mais 

as vendas de solugoes de software Netscape nos 

mercados domestico e empresarial (Netscape, 
1998). 

A decisao da empresa tinha partido de fun- 
cionarios que ja colaboravam com a comunidade 
de software livre e que tinham sido muito influen- 
ciados por uma palestra - depois transformada em 
um influente artigo, chamado a “A catedral e o ba- 
zar” - proferida pelo programador de software livre, 
Eric Raymond, numa conferencia em 1997. Nessa 
palestra, Raymond descrevia as virtudes tecnicas 
da organizagao do trabalho no software livre, en- 
fatizando a descentralizagao das responsabilidades, 
a autoiniciativa e o processo aberto de revisao por 
pares que permitia uma rapida identificagao e cor- 
regao de erros (Raymond, 2001a). Essa explicagao 
do sucesso do software livre em criar ferramentas 
tao eficientes foi imediatamente tornada referenda 
e influenciou muitas decisoes posteriores de empre- 
sas tradicionais que aderiram ao software livre. 

O interesse da Netscape por este tipo de sof- 
tware livre foi visto como uma janela de oportuni- 
dade para atrair outras empresas para o projeto do 
software livre. Muitos programadores acreditavam 
que o projeto do software livre, embora um grande 
sucesso tecnico, era prejudicado por uma postura 
purista, confrontativa e desnecessariamente politi- 
ca do seu fundador original, Richard Stallman. Tal 
postura afastava as empresas e comprometia o cres- 
cimento do projeto. Assim, dez dias apos o anuncio 
da Netscape, Eric Raymond, que havia sido con- 

tratado como consultor pela empresa para auxiliar 

na transigao no seu modelo de negocios, reune em 

Palo Alto, California, alguns dos principals lideres 


da comunidade de software livre (como Chris Pe- 

terson, john “Maddog” Hall e Michael Tiemann) 
para tragar estrategias para esse novo cenario de in- 

teresse das corporagoes. Linus Torvalds participou 
da reuniao por video-conferencia. Stallman nao foi 

convidado. Na reuniao, os participantes decidem 
pela mudanga do termo free software para o termo 
open source software {software de codigo aberto), que 

consideram menos politico e ambiguo (pois^ra? em 
free software dava a entender tanto que o software 
era livre como gratis) e por uma mudanga no dis- 
curso da comunidade, da defesa moral da liberdade 
(de acesso ao codigo) para uma defesa pragmatica 
da superioridade tecnica do modo de produgao do 
software (abordagem que tinha defendido no seu 
famoso artigo “A catedral e o bazar”). Cinco dias 
depois, Raymond faz um anuncio publico a comu- 
nidade, propondo a substituigao do termo “ softwa- 
re livre” pelo termo “software de codigo aberto”: 

O problema [com o termo “ software livre”] e 
duplo. Em primeiro lugar, e confuso. O termo 
livre [free] e muito ambiguo (algo com o que a 
propria propaganda da Free Software Founda- 
tion tern que lidar constantemente). Sera que 
free quer dizer “sem custos”? Ou sera que sig- 
nifica “livre para ser modificado por qualquer 
um”, ou mesmo uma outra coisa? Em segundo 
lugar, o termo deixa muitos empresarios ner- 
vosos. Embora isso nao me incomode nem um 
pouco, nos temos agora um interesse pragmati- 
co em converter essas pessoas, em vez de enfiar 
o dedo nos seus narizes. Existe agora a oportu- 
nidade de conseguir grandes ganhos no mun- 
do empresarial sem colocar em risco os nossos 
ideais e nosso compromisso com a excelencia 
tecnica - entao e hora de mudar de estrategia. 
Precisamos de um rotulo novo e mais adequa- 
do. [...] Devemos explicar publicamente os 
motivos para essa mudanga. Linus Torvalds 
disse no evento World Domination 101 que 
a cultura do codigo aberto precisa fazer um 
esforgo serio para se apropriar dos Desktops e 
abragar o mundo dos negocios. Claro que ele 
esta certo - e essa mudanga de rotulo e parte 
do processo. Ele diz que estamos dispostos a 
trabalhar com o mercado e coopta-lo para os 
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nossos proprios propositos, em vez de perma- 
necermos parados numa posigao marginal e 
confrontativa (Raymond, 1998). 

Com a adesao da Netscape ao software livre e 

a posterior aproximagao de outras grandes empre- 

sas - como a IBM a Microsoft, que dominava o 

mercado de softwares no modelo tradicional, come- 

gou a mostrar preocupagao. Em agosto de 1998, ela 

encomendou um memorando confidencial para o 

seu gerente de programas, Yinod Valloppillil, para 

avaliar as ameagas levantadas pelo crescimento do 

software de “codigo aberto” a lideranga de mercado 

da empresa. O relatorio, que vazou no final de ou- 
tubro daquele ano (e, devido a data de vazamento, 
ficou conhecido como “Halloween papers”), mos- 
trava a atengao que a Microsoft dava ao fenomeno 
do software livre e a potencialidade que via no me- 
todo de produgao: 

O software de codigo aberto e um processo 
que promove a rapida criagao e preparagao de 
caracteristicas adicionais e corregao de falhas 
numa base de codigo/conhecimento ja existen- 
te. Recentemente, paralelamente ao crescimen- 
to da Internet, projetos de software de codigo 
aberto adquiriram profundidade e complexi- 
dade tradicionalmente associadas com projetos 
comerciais como Sistemas Operacionais e ser- 
vidores para uso em situagoes criticas. Assim, o 
software de codigo aberto representa uma ame- 
aga direta, de curto prazo, aos rendimentos e a 
plataforma da Microsoft - particularmente no 
espago de servidores. Alem disso, o paralelismo 
intrinseco e a livre troca de ideias no software 
de codigo aberto tem beneficios que nao sao 
replicaveis no nosso modelo de licenciamen- 
to atual e representam assim, no longo prazo, 
uma ameaga a repercussao junto aos programa- 
dores (Valloppillil, 1998, s/p). 

Com a aproximagao de grandes empresas 
como a Netscape e a IBM e a preocupagao docu- 
mentada da maior empresa do setor, os defensores 
do software de codigo aberto acreditavam que preci- 
savam divulgar o seu potencial comercial e promo- 
ver os novos modelos de negocios que deslocavam a 


fonte de rendimentos da venda de software para ser- 
vigos e produtos agregados. Em fevereiro de 1998, 
um mes apos o amincio da Netscape, os ativistas 
do codigo aberto ja haviam fun dado uma organi- 
zagao (a Open Source Initiative, presidida por Ray- 
mond) para promover os novos modelos de nego- 
cio e, no ano seguinte, o mesmo Raymond publica 
outro artigo influente, dessa vez sistematizando os 
modelos de negocio existentes - baseando-se na 
experiencia da Netscape e tambem no que faziam 
as empresas originalmente ligadas ao software livre 
como a Red Hat, a VA Linux, a Cygnus Solutions 
e a O’Reilly & Associates. Os modelos de negocios 
que descreviam eram principalmente quatro: 

Posicionador de mercado : Neste modelo, utiliza- 
-se o software de codigo aberto para criar ou 
manter uma posigao de mercado para um sof- 
tware proprietario que gera a receita direta. Na 
sua variante mais comum, um software cliente 
de codigo aberto proporciona a venda de sof- 
tware para servidores ou rendimentos de assi- 
natura ou publicidade associados com um por- 
tal. A Netscape Communications Inc. estava 
seguindo esta estrategia quando abriu o codi- 
go do navegador Mozilla no comego de 1998. 
[. . .] Enfeite de bugigangas: Este modelo e para 
fabricantes de hardware. Pressoes de mercado 
forgaram companhias de hardware a escrever 
e manter software (desde drivers para disposi- 
tivos, passando por ferramentas de configura- 
gao, ate sistemas computacionais inteiros), mas 
o software em si nao e o centro do lucro. E uma 
despesa indireta, normalmente substancial. 
Nesta situagao, abrir o codigo e uma opgao 
autoevidente. [...] De a receita , a bra um restau- 
rante: Neste modelo abre-se o codigo de um 
software para criar uma posigao de mercado, 
nao para um software fechado (como no caso 
do posicionador de mercado), mas para servi- 
gos. Este modelo foi primeiro explorado pela 
Cygnus Solutions, talvez a primeira empresa 
de software de codigo aberto (1989). [. . .] Aces- 
sorios: Neste modelo, vende-se acessorios para 
software de codigo aberto. Numa ponta, ven- 
de-se canecas e camisetas; noutra, documenta- 
gao profissionalmente editada e produzida. A 
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O’Reilly & Associates Inc., editora de muitos 
excelentes volumes de referenda sobre software 
de codigo aberto, e um bom exemplo de uma 
empresa de acessorios (Raymond, 2001b). 

Sistematizando a relativamente restrita expe- 

rience do software livre de entao, Raymond pode 
apresentar para o mercado, de forma organizada, os 
modelos bem-sucedidos que haviam sido estabele- 

cidos pelas empresas que haviam explorado as pos- 

sibilidades de negocio com o software livre nos anos 
de 1990. A acuidade desta percepgao e descrigao 

podem ser medidas pelo fato de que, ainda hoje, 
esses sao os quatro principals modelos de negocio 
de um setor produtor de software livre, cujo valor de 
mercado foi esrimado ern 7.000 em 17 hilhoes de 

euros (Ghosh, 2006) e no qual se envolvem empre- 

sas como a IBM, a Nokia e a HP. 

O regime publico/cientifico de produgao do 
conhecimento 

Como dissemos, uma das hipoteses que estru- 
tura o presente trabalho e a de que a produgao do 
software livre, ou de codigo aberto, se liga, por rai- 
zes historicas, ao regime de produgao do conheci- 
mento tipico da ciencia/ tecnologia 1 5 produzida sob 
o regime publico - cujo locus privilegiado sao insti- 
tuigoes como universidades e laboratories governa- 
mentais - em oposigao ao conhecimento produzi- 
do sob o regime privado - principalmente, embora 
nao de forma exclusiva, nos laboratories empresa- 
rias e departamentos privados de P&D. Ate aqui, 
viemos tratando o regime publico/cientifico de 

produgao do conhecimento apenas em termos abs- 

tratos. sem definir suas caracteristicas constitutivas. 

A partir de agora, faremos um esforgo no sentido 

de caracteriza-lo a partir das dimensoes que mais 

importam para a constituigao da comunidade de 

software livre e, ao mesmo tempo, que determina- 

ram a sua maior eficiencia: a forma de organizagao/ 

gestao do trabalho, o regime de recompensa/mo- 

tivagao subjetiva e a forma de gestao da proprie- 

dade intelectual . Essa reconstrugao inspira-se, de 
um lado, nos estudos de sociologia da ciencia (em 
especial, os que buscaram caracterizar a estrutura 


organizacional da ciencia e suas praticas constituti- 
vas: Merton, 1957, 1963; Bourdieu, 1975 e 2004; 
Shinn, 1980, 2000a; 2000b; 2008a); e, de outro, 
nos estudos sobre a estrutura organizacional da co- 
munidade hacker ou de software livre (Raymond, 
1999, 2000, 2001a, 2001b; DiBona et al., 1999; 
Bonaccorsi e Rossi, 2003, entre outros). 

Embora os estudos classicos de sociologia da 
ciencia nao enfatizem as praticas cientificas da 
perspectiva da gestao do trabalho, inumeros estu- 
dos o fizeram posteriormente. Desde as primeiras 
pesquisas sobre gestao do trabalho de cientistas em 
grandes laboratories (por exemplo, Pelz e Andrews, 
1966; Glaser, 1964; Kaplan, 1965) ate estudos 
mais recentes sobre gestao da inovagao e eficiencia 
da produgao e difusao do conhecimento (Dasgup- 
ta e David, 1994; Mazzoleni e Nelson, 1998; Nel- 
son, 2004; Owen-Smith, 2001; Fleming e Sorenson, 
2001, 2004) ressaltam as vantagens inerentes aos 
aspectos organizacionais da ciencia para a gestao do 
trabalho em pesquisa e desenvolvimento. 16 

Nessa perspectiva, uma primeira dimensao es- 
sencial que concerne a organizagao do trabalho no 
regime publico/cientifico e o regime de excelencia 
que, em alguma medida, organiza a formagao de 
hierarquias nesse ambito. 

Esse regime tern varios aspectos; o primeiro e a 
valorizacao, institucional e informal, da meritocra- 

cia. Esta e pensada, nesse caso, como um regime de 
controle do trabalho e hierarquizagao profissional 
baseado no reconhecimento do “merito” que encar- 
na, de forma mais ou menos precisa, a competencia 
em uma determinada area. O merito funciona, nes- 
se caso, portanto, como um mecanismo especlfico 
de formagao de “liderangas”, as assim chamadas “li- 
derangas cientificas ou academicas”. Dito de outro 
modo, o controle de uma area de pesquisa - ou de 
um projeto de desenvolvimento de software, para 
aproximarmo-nos do nosso objeto - e exercido 
por aquele, ou aqueles, que tern mais legitimida- 
de de faze-lo porque sao reconhecidos, pelos outros 
pesquisadores/desenvolvedores, como tendo mais 
merito/competencia para tan to. E evidente que o 
funcionamento da meritocracia, tal como a descre- 
vemos aqui, tem uma dimensao idealizada, uma 
vez que, na pratica, sobretudo a partir do fortale- 
cimento da institucionalizagao da avaliagao meri- 
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tocratica - a cristalizaqao do “merito” em titulos e 
indices de produdvidade e eficiencia academica 
o controle do processo de controle da produqao do 
conhecimento e a consequente formagao de lide- 
ranqas cientificas tornou-se muito mais complexo. 

De toda a forma, como na comunidade de sof- 
tware livre a institucionalizaqao do merito pratica- 
mente inexiste, 17 e mais facil propor a existencia de 
formas espontaneas de formaqao de lideranqas que, 
sabemos, sao centrais para a compreensao do fun- 
cionamento dos projetos de desenvolvimento. 

Um segundo aspecto fundamental do regime 
de excelencia cientifico/publico e a revisao por pa- 
res, ou seja, um trabalho e considerado “correto” ou 
“valido”, do ponto de vista cientifico, apenas quan- 
do os outros cientistas assim o reconhecem, o que 
pressupoe uma revisao minuciosa de cada trabalho. 
Mas a revisao por pares nao avalia apenas “valida- 
de ou correqao” de uma teoria mas, tambem, a sua 
qualidade e a sua legitimidade em relagao a outras 
pesquisas. 

A revisao por pares e um dispositivo institucio- 
nal da ciencia que esta estritamente ligado, de um 
lado, a dimensao publica da atividade - e a ampla 
divulgaqao de resultados que permite que os cien- 
tistas tenham livre acesso as pesquisas e possam, a 
partir disso, revisar procedimentos e conclusoes - e, 
de outro, ao seu carater meritocratico: o reconheci- 
mento dos “melhores” em uma determinada area 
depende diretamente da avaliaqao que os cientistas 
fazem do trabalho uns dos outros. 18 

Para alguns, o processo social de reconheci- 
mento da confianqa/qualidade das pesquisas (via 
revisao por pares) e um dos motivos fundamentals 
para se criticar o carater racional da ciencia; para 
outros, ao contrario, e justamente o que garante a 
racionalidade cientifica. 19 

Mas nao e so a “racionalidade” da ciencia que 
depende da revisao por pares - que pressupoe, 
nunca e demais lembrar, a ampla divulga^ao dos 
resultados e procedimentos de pesquisa - mas, 
tambem, o carater eficiente e cumulativo da cien- 
cia: o fato de as pesquisas serem amplamente di- 
vulgadas impede a duplica^ao de esforqos desne- 
cessarios e faz com que o conteudo das pesquisas 
cientificas seja acumulado ao longo da historia 
(Nelson, 2004, p. 456). 20 


No caso do desenvolvimento de software, o fato 
de cada linha de codigo ser amplamente divulgada 
para a comunidade, que tern, assim, a possibilidade 
de as revisar em busca de erros e inconsistency - 
um procedimento, no geral, identico ao da revisao 
por pares -, permite nao so que a comunidade re- 
conheqa seus melhores programadores - que, na 
maioria das vezes, controlam “espontaneamente” os 
projetos mais importantes - mas, tambem, que essa 
atividade se torne consideravelmente mais eficien- 
te: nenhum erro fica muito tempo sem correqao, 
nenhum problema evidente fica muito tempo sem 
soluqao e, sobretudo, ninguem reescreve uma linha 
que ja tenha sido escrita por outra pessoa, ou seja, o 
carater cumulativo da atividade impede que esfor- 
qos sejam despendidos desnecessariamente. 

Ainda do ponto de vista da organizaqao do 
trabalho, outra dimensao que merece destaque no 
regime publico/cientifico de produqao do conhe- 
cimento e o carater autogestionado do trabalho 
individual. Do ponto de vista ideal, os cientistas 
que trabalham no ambito publico tern maior liber- 
dade na escolha dos problemas e das tarefas mais 
relevantes e mais espaqo para determinagao sobre 
quais destes melhor se adaptam as suas habilidades 
e competencias. Alem disso, em alguma medida, os 
cientistas escolhem de forma mais ou menos livre 
como empregar o proprio tempo, tanto no sentido 
de quanto e quando se dedicar como de quais ta- 
refas e problemas precisam de mais tempo e quais 
devem ser encaradas primeiro. Assim, nao sao in- 
comuns as historias de cientistas que consomem 
madrugadas em torno de um mesmo experimento, 
ou dias e dias em torno de um unico problema em- 
pirico ou teorico. 

No caso do desenvolvimento de software, es- 
sas historias tambem nao sao incomuns. O pro- 
prio desenvolvimento do Unix configura-se como 
um exemplo esclarecedor do quanto a autogestao 
do proprio tempo de trabalho pode ser produtiva 
nesses casos: Thompson, empregado do Bell Lab, 
desenvolveu o kernel do Unix durante suas ferias de 
verao de 1969, quando tinha pleno controle do seu 
tempo, tanto assim que trabalhou em ritmo inten- 
so para produzir um sistema operacional automa- 
tico e multiusuario em aproximadamente quatro 
semanas. 
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Esta questao - da dedicaqao intensa e do con- 
trole do proprio tempo - remete imediatamente a 
outra dimensao essencial do regime publico/cien- 
tffico de produqao do conhecimento: a motivaqao 
subjetiva. O sistema de recompensas da ciencia 
funciona de forma consideravelmente distinta do 
suposto sistema economico/liberal de maximizaqao 
de lucros. A motivaqao subjetiva dos que se dedi- 
cam a busca do conhecimento, considerando-se 
que essa aqao se desenrola dentro de uma teia de 
relaqoes sociais que configuram a estrutura institu- 
cional da ciencia, nao e financeira, mas de outra 
natureza. Os sociologos da ciencia empenharam- 
-se sistematicamente na tentativa de entendimento 
do funcionamento desse sistema de recompensas 
(Merton, 1957; Bourdieu, 1975, 2004; Hagstrom, 
1965) e, no geral, o descrevem como um sistema no 
qual a motivaqao e socialmente construida e intrin- 

secamente dupla: os cientistas buscam, ao mesmo 

tempo, o reconhecimento social do seu trabalho 

(por parte dos seus pares) e uma contribuiqao para 

o conhecimento de um determinado problema ou 

questao. Bourdieu descreve essa “ambiguidade es- 
trutural da ciencia nos seguintes termos: 

Ha uma especie de ambiguidade estrutural do 
campo cientifico (e do capital simbolico) que 
poderia ser o principio objetivo da “ambiva- 
lencia dos cientistas”, ja evocada por Merton, 
a proposito das reivindicaqoes de prioridade: a 
instituiqao que valoriza a prioridade (ou seja, 
a apropriaqao simbolica), valoriza tambem o 
desinteresse e a “dedicaqao desinteressada ao 
avanqo do conhecimento”. O campo impoe, 
simultaneamente, a competiqao “egoista” [...] 
e o “desprendimento” (Bourdieu, 2004, p. 77). 

Bourdieu deixa explicita a indissociabilidade 
entre a competiqao e a colaboraqao na dinamica de 
funcionamento da ciencia: os cientistas colabo- 
ram entre si - compartilhando os resultados de 
suas pesquisas - e, ao mesmo tempo, o fazem para 
competir por reconhecimento, fonte de poder no 
campo. Essa dualidade, tipica das trocas simbolicas, 
fez com que a dinamica das trocas cientificas pu- 
desse ser explicada, tambem, pela teoria da dadiva, 
que atribui a “doaqao” esse carater intrinsecamente 


ambiguo, em que a generosidade e inseparavel do 
interesse (Hagstrom, 1972). 

E interessante notar que essa dualidade ine- 
rente a ciencia se expressa em um mesmo “mo- 
mento”: o da publicaqao dos resultados de pesqui- 
sa. A publicaqao e, simultaneamente, um ato de 
generosidade (o cientista doa o seu conhecimento 
para os outros) e um ato de disputa por merito e 
por reconhecimento (o cientista espera, por meio 
dela, obter reconhecimento/prestigio/poder entre 
os seus pares). 

O mesmo ocorre no processo de desenvolvi- 

mento de software no regime publico/cientifico, ou 

seja, no software livre: 

Emergindo da universidade e do ambiente de 

pesquisa, o movimento [de software livre] ado- 

tou a motivaqao da pesquisa cientffica, transfe- 

rindo-a para a produqao de tecnologia que tern 

um potencial valor comercial. Compartilhar 

resultados permite ao pesquisador melhorar 

seus resultados de pesquisa a partir da resposta 

de outros membros da comunidade cientffica. 

ganhar o reconhecimento e, por conseguinte, 

o prestigio por seu trabalho. A mesma coisa 

acontece quando o codigo e compartilhado 

(Bonaccorsi e Rossi, 2003, p. 1245). 

Assim, chegamos a ultima, e talvez mais im- 
portante, dimensao do regime cientifico/publico 
de produqao do conhecimento: o imperativo de 
publicaqao dos resultados. Para isso, a propriedade 
intelectual assume lugar central. Existindo nos dois 
regimes (no publico/cientifico e no privado/empre- 
sarial) a propriedade intelectual assume sentidos 
completamente diferentes nos dois casos. 

No regime privado/empresarial, em que o im- 

perativo da competiqao entre firmas impoe a dina- 
mica do segredo ao processo de inovaqao e produqao 
do conhecimento, a propriedade intelectual torna- 

-se um dispositivo que restringe a reproduqao e a 

utilizaqao do conhecimento. Ja no regime publico/ 
cientifico, em que o imperativo da publicaqao e o 
pilar sobre o qual se estruturam todas as praticas so- 
ciais de produqao do conhecimento (a meritocracia, 
a lideranqa espontanea, a revisao aberta por pares 
e a motivaqao subjetiva), a propriedade intelectual 
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e mobilizada para autorizar a copia, a utilizagao e a 
divulgagao, acelerando o processo de i novagao. 

Essa relagao entre abertura da ciencia e acelera- 
gao da inovagao foi destacada por autores como Ri- 
chard Nelson, para quern “manter a ciencia aberta 
e a politica mais efedva para garantir que o publico 
extraia, dela, beneffcios praticos” (Nelson, 2004, p. 
456). Da mesma forma, Sorenson e Fleeming desta- 
cam que a norma da publicagao e o que explica a in- 

fluencia positiva da ciencia sobre as taxas de inovagao 

tecnologica: “Mais do que acumular conhecimen- 

to para o ganho privado, a norma do comunismo 

Idos resultadosl, tambem conhecida como abertura, 

compete as descobertas a se disseminarem para ou- 

tros [...] o que aumenta a eficiencia das advidades 

cienrificas” (Fleeming e Sorenson, 2004, p. 1616). 

Apesar da apologia desses e outros autores a 
eficiencia inerente a produgao do conhecimento 
sob o regime publico/cientifico, a descrigao que eles 
fazem, e a que aqui fizemos, do funcionamento da 
ciencia sob o regime publico condiz muito pouco 
com a realidade atual. E consenso de que praticas 
cientificas vem passando por profundas alteragoes 
que, em geral, as aproximam do regime privado/ 
empresarial de produgao do conhecimento. Segun- 
do Shinn e Famy: 

Na busca por novas formas de financiamento, 
e submetidas a pressao das demandas economi- 
cas e sociais, as instituigoes cientificas evoluem 
para modelos mais proximos da industria. Elas 
se mercantilizam e tendem a submeter-se aos 
interesses comerciais e a inscrever-se numa 16- 
gica de oferta economica que as vezes substitui, 
as vezes se mistura a logica de oferta cientifica 
(Shinn e Famy, 2006a, p. 23). 

O incentivo ao patenteamento dos resultados 
de pesquisas realizadas nas institutes publicas e a 
politica de direitos autorais das principals publica- 
goes cientificas da atualidade alteram radicalmente 
a vigencia do imperativo da ampla divulgagao dos 
resultados (Milissard, Gingras e Gemme, 2003). 
Por outro lado, a orientagao de pesquisas via finan- 

ciamentos especificos, a diminuigao crescente dos 

prazos e a cobranga crescente por produtividade 

individual configuram-se como novos dispositivos 


de gestao do trabalho que subvertem o carater au- 

togestionado da atividade cientifica, aproximando 

o funcionamento da universidade ao de empresas 

modernas (Yates, 2000; Shinn e Famy, 2006a e b; 
Kleinman e Valias, 2001, 2008). 

Mas mesmo em meio a tantas muda 11915 pro- 
fundas e inegaveis, alguns pesquisadores ainda ressal- 
tam aspectos de continuidade e permanencia (Shinn 
e Famy. 2006a e b; Godin e Gingras, 2000). Alem 
disso, apesar dessas mudangas que vem afetando as 
praticas sociais que constituem a ciencia nos seus 
aspectos mais fundamentals, o regime publico/cien- 
tifico de produgao do conhecimento parece ser, em 
muitos casos, muito mais eficiente do que o regime 
privado/empresarial, o que, no caso do desenvolvi- 
mento de programas de computador, fez com que 
ele se impusesse como regime dominante, inclusive 
entre as grandes empresas de software. 

Produtos mercantis e extramercantis 

A disputa por consumidores entre o software 
produzido no regime publico e o produzido no re- 
gime privado implica uma competigao sui generis 
entre um produto mercantil e outro extramercantil. 
Mas em que terreno ocorre essa disputa? No mer- 
cado? Como pode um produto sem valor mercan- 
til disputar mercado com um produto mercantil? 
Quando o servidor Apache da Fundagao Apache 
compete com o Internet Information Services da 
Microsoft e ganha mais consumidores, o que te- 
mos? Uma “conquista de mercado” pelo Apache? 

A historia do Apache e, de todas aquelas do 
software livre, talvez a mais significativa para enten- 
dermos a interagao entre comunidade e mercado. 
O Apache domina “o mercado de servidores” prati- 
camente desde o comego da Web, desde o primeiro 
semestre de 1996, para sermos precisos. O projeto 
Apache nasceu para coordenar corregoes e melho- 
ramentos feitos voluntariamente por programado- 
res e webmasters para o primeiro servidor popular, 
o “http daemon” (httpd), desenvolvido de forma 
“livre ” 21 por Robert McCool, da Universidade de 
Illinois. Quando McCool e outros programadores- 
-chave do httpd foram contratados pela Netscape 
para desenvolver seu servidor em 1994, diversos 
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Fonte: Netcraft, 2008. 

Versao colorida disponfvel em <http://news.netcraft.com/archives/2010/06/l6/june-2010-web-server-survey.html>. 


outros que utilizavam o software continuaram de- 
senvolvendo-o individualmente, adicionando fun- 
goes e corrigindo falhas. O projeto Apache nasce, 
em fevereiro de 1995, como um consorcio de oito 
destes programadores (que se chamam de “grupo 
Apache”) para coordenar os esforgos de desenvolvi- 
mento do httpd por meio da Internet. Em apenas 
um ano, o software reunindo as melhorias sobre o 
codigo do httpd ja e o servidor Web mais utilizado 
no mundo e permanece assim ate hoje. 

Embora tenha sido, desde o comedo, um su- 
cesso na disputa “por mercado”, o Apache foi ini- 
cialmente concebido como um “esforgo voluntario, 
completamente financiado por seus membros e 
nao por vendas comerciais” e que buscava perma- 
necer como um servidor “de dominio publico”. 
Ele tinha sido desenvolvido “para resolver questoes 
de provedores www e programadores de httpd de 
tempo parcial relativas ao mau comportamento do 
httpd” 22 . Era, portanto, um empreendimento ex- 


traprofissional de alguns programadores, embora 
diretamente ligado as suas atividades profissionais. 
Um dos fundadores do grupo Apache descreveria, 
em um artigo em coautoria em 1997, a motivagao 
dos programadores do projeto dessa maneira: 

Cada voluntario do grupo Apache tem (pelo 
menos) um emprego “de verdade”, normal- 
mente relacionado com servigos de Web ou 
pesquisa sobre protocolos. Eles colaboraram 
na produgao e suporte ao servidor Apache ape- 
nas por autointeresse esclarecido: ao consorciar 
seus esforgos, o produto resultante e muito 
mais funcional e robusto do que o que pode- 
riam ter produzido individualmente (Fielding 
e Kaiser, 1997, s/p). 

Esse depoimento indica a natureza da colabo- 
ragao no desenvolvimento do software. De um lado, 
temos os pesquisadores da universidade, para quern 
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a colaboragao e norma profissional; de outro, os web- 
masters e programadores que competem na provisao 
de services para empresas (elabora$ao e manuten$ao 
de paginas Web). Como o software do servidor e ape- 
nas um meio para a hospedagem do site, que e o 
verdadeiro produto final, os programadores de pa- 
ginas Web podem colaborar no software do servidor, 
o que facilita o trabalho de todos, sem dar vantagem 
competitiva para nenhum dos programadores de 
site. Alem disso, o desenvolvimento de uma plata- 
forma comum garante que os padroes da Web sejam 
universais (pois as paginas serao servidas da mesma 
forma), sem o dominio de uma empresa que os pri- 
vatize, garantindo os fundamentos da competiqao de 
mercado. A Funda$ao Apache explica: 

Nos acreditamos que as ferramentas de publi- 
caqao online devem estar nas maos de todos e 
que as empresas de software deveriam extrair 
dividendos da provisao de serviqos adicionais 
tais como modulos especializados e suporte, 
entre outras coisas. Nos sabemos que normal- 
mente se ve como uma vantagem economica 
para uma empresa o “dominio” do mercado - 
na industria do software, isso significa controle 
estrito de um canal, de maneira que os outros 
precisam pagar para o seu uso. Isso e feito tipi- 
camente pela “posse” de protocolos pelos quais 
empresas conduzem negocios as custas de to- 
das as outras empresas. Na medida em que os 
protocolos da World Wide Web permaneqam 
sem a “posse” de uma unica empresa, a Web 
permanecera um campo onde poderao jogar 
empresas pequenas e grandes. Por isso, a “pro- 
priedade” dos protocolos precisa ser evitada . 23 

Mas, o que significou, do ponto de vista eco- 
nomico, o dominio do Apache no mercado de 
servidores? Como o Apache e uma ferramenta li- 
vre, disponivel gratuitamente na Web, nao se pode 
falar, rigorosamente, que ela dominou o mercado, 
ja que e um produto nao mercantil. Podemos, ao 
contrario, dizer que a oferta desse produto redu- 
ziu o mercado de servidores. Em outras palavras, a 
oferta de um software concorrente nao mercantil, 
de qualidade igual ou superior aos produtos mer- 
cantis, impediu que o mercado de software para 


servidores se estabelecesse e se expandisse em toda 
a sua potencialidade. Embora concorressem por 
consumidores, alguns produtos estavam no merca- 
do, enquanto outros estavam fora. E cada vez que 
o produto extramercantil ganhava um consumidor, 
stricto sensu, ele reduzia o mercado. O software livre 
pode ser visto, entao, como uma barreira a amplia- 

qao do mercado de venda de software e, se levarmos 

em conta as motivacoes historicas de Stallman e 

dos primeiros programadores de software livre, essa 

barreira a expansao do mercado e uma reaqao a na- 

tureza anticolaborativa do trabalho de produqao de 

software no regime privado . 

Se a tese de Eric Raymond e dos outros ativis- 
tas do software de codigo aberto estiver correta, a 
vitoria do Apache na disputa com o Internet Infor- 
mations Service da Microsoft e outros concorrentes 
menores nao se deve apenas a sua gratuidade, mas 
tambem a qualidade tecnica que e fruto da maneira 

como o software e produzido. O regime publico/ 
cientifico, traria as seguintes vantagens: 

• Organizaria o trabalho de maneira mais efi- 
ciente, permitindo que os proprios programa- 
dores determinem onde melhor podem alocar 
suas competences e permitindo tambem que 
a comunidade identifique “espontaneamente” 
as lideranqas, de maneira estritamente merito- 
cratica, dispensando as credenciais hierarquicas 
(como titulos e cargos). 

• Permitiria uma evoluqao tecnica mais acen- 
tuada, impedindo que o desenvolvimento de 
uma mesma funcionalidade fosse duplicado 
em firmas concorrentes. Duas iniciativas po- 
tencialmente concorrentes que se unam num 
projeto de software de codigo aberto passam a 
acelerar o processo de desenvolvimento. 

• Permitiria a identifica^ao mais rapida de falhas e 
novas demandas, permitindo que o usuario re- 
late e, se tiver competencia, resolva o problema 
ou proponha melhorias. Seria um processo de 
monitoramento aberto da estrutura e da fun- 
cionalidade do programa que geraria correqoes 
mais eficientes e inovaqoes mais frequentes. 

Entendemos que, se essas caracterfsticas foram, 
de fato, determinantes para o sucesso competitivo 
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do software livre, elas devem ter forgado uma mu- 
danga nas industrias tradicionais que tiveram que 
adotar alguns desses procedimentos para concorrer 
de forma eficiente com as alternativas nao mercan- 
tis, em um processo que poderia ser descrito em 
termos “evolucionarios”. 24 Se a forma de produgao 
do software de codigo aberto mostrou-se mais efi- 
ciente do que a produgao de software proprietario 
e reduziu em mais da metade o mercado de venda 
de software para servidores, entao as empresas atu- 
ando na esfera mercantil precisam, para continuar 
competindo, adotar as praticas mais eficientes do 
software de codigo aberto e, consequentemente, 
migrar sua fonte de recursos para servigos e pro- 
dutos associados - sejam softwares proprietaries as- 
sociados ao software livre ou servigos de instalagao, 
personalizagao e manutengao. Em outras palavras, 
a eficiencia da alternativa nao mercantil pode ter 

obrigado as empresas que nao conseguem mais 

competir a colaborar nessa esfera nao mercantil e 

concentrar a competigao em servigos e produtos 

associados ao software como, por exemplo, manu- 

tencao e customizacao . 

Isso talvez explique um levantamento recente 
sobre os vfnculos empregaticios dos programadores 
do kernel do Linux (nucleo do sistema operacional), 
indicando que apenas 18,2% deles nao tern vfnculos 
empregaticios com empresas que contribuem com 
o kernel - assim, supostamente, nao contribuem 
para o kernel na qualidade de empregados de em- 
presas (Kroah-Hartman et al. , 2009). Embora os 
diferentes levantamentos ja feitos sobre a profissio- 
nalizagao dos programadores de software livre nao 
tenham metodologias e universos uniformes, o que 
dificulta a comparagao, e possfvel fazer algumas in- 
ferences sobre tendencias gerais. Sabemos que nos 
anos de 1980 praticamente nao havia programado- 
res pagos dedicados a colaborar com o projeto GNU 
e que, em 2002, no levantamento feito por Ghosh, 
conhecido como Floss Survey, apenas 16% dos pro- 
gramadores entrevistados eram pagos para colaborar 
com desenvolvimento, e uma parte nao determinada 
desses 16% era paga por entidades nao mercantis, 
como universidades ou fundagoes (Ghosh, 2002). 
De forma que e bastante provavel que a participagao 
de programadores pagos por empresas para colabo- 
rar em projetos de software livre tenha sido original- 


mente muito baixa ou nula e tenha aumentado, com 
um salto no perfodo de “mercantilizagao” que vai 
de 1997 ate 1999 e esteja crescendo gradualmente 
a partir de entao, ate a altfssima concentragao atu- 
al, quando mais de 80% dos colaboradores sao as- 
salariados em projetos de grande interesse mercantil 
como o kernel do Linux ou o servidor Apache. 

Se nossa hipotese estiver correta, entao pode- 
mos tirar algumas conclusoes e propor especula- 
goes sobre a subsistencia de um regime publico de 
produgao no setor de software inserido no contexto 
mais geral de uma sociedade de mercado. Parece- 
-nos que a eficiencia do regime de produgao pu- 
blico/ cientffico forgou, por um processo competi- 
tive - de natureza sui generis, porque nao se tratava 
de uma entidade com natureza propriamente eco- 
nomica -, as empresas tradicionais a migrarem seu 
modelo de negocios para servigos e produtos asso- 
ciados e a colaborarem na produgao do software. 
Assim, a eficiencia do regime de produgao publico 

“protegeu” o mercado de software para servidores da 

mercantilizagao, mas apenas ao custo de forgar as 

empresas do setor a supermercantilizarem os servi- 

gos para subsidiar a desmercantilizagao do software. 

Para aqueles que, como nos, entendem que a 
desmercantilizagao da produgao de software e positi- 
va porque impede a degradagao do processo colabo- 
rativo do regime publico/cientffico em competigao 
e transformagao da propriedade comum do software 
em propriedade privada - o que resulta em perda de 
qualidade e barreiras de pregos -, talvez seja o caso 
de perguntar se nao estarfamos presenciando um 
processo de transformagao do proprio regime publi- 
co de produgao de software - suas praticas, valores e 
estrutura organizacional -, a medida que ele intera- 
ge e, por vezes, se subordina ao regime empresarial. 
Embora a logica do processo de competigao tenha 
levado as empresas a colaborar na produgao do sof- 
tware, transferindo a mercantilizagao e a competigao 
economica para o setor de servigos, percebemos al- 
gumas tendencias notaveis de degradagao do proces- 
so colaborativo de produgao de softwares-. 

• Empresas de software livre tern utilizado diver- 
sas estrategias para nao compartilhar progra- 
mas que desenvolvem a partir de codigo com 
licengas copyleft (como a GPL). Essas estrate- 
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gias incluem disponibilizar o codigo-fonte de 
maneira pouco publica ou postergar a publica- 
gao, entre outras (Henkel, 2006). 

• Empresas estao transferindo seus servigos da 
venda do software para a execugao de servi- 
gos pela Internet. Como nao distribuem o 
software (pois este e executado pela Internet 
a partir de um servidor), essas empresas nao 
precisam, de acordo com os termos da licenga 
GPL, compartilhar as mudangas que fizeram 
a partir de um codigo licenciado em copyleft. 
Na revisao dos termos da licenga GPL, em 
2007, discutiu-se a inclusao de uma clausula 
para obrigar a distribuigao do codigo tambem 
quando o software e acessado remotamente 
(um dispositivo que ja aparece numa varian- 
te da GPL chamada Afero-GPL), mas nas ne- 
gociagoes com a comunidade (da qual fazem 
parte as empresas interessadas), essa clausula 
foi abandonada. Esse tipo de nao comparti- 
Ihamento de modificaqoes de softwares livres 
que nao sao distribuidos, mas disponfveis pela 

Internet rende a rresrer com o advenro de ser- 

vices de “computagao nas nuvens”, como re- 
des sociais, webmails e sites que disponibilizam 
streamminz de videos pela Web. E por isso que 
Richard Stallman tern chamado a computagao 

nas nuvens de uma “cilada” (Stallman, 2008). 

• Embora a licenga de software livre mais utili- 
zada hoje ainda seja a GPL, a maior parte das 
empresas tern preferido licengas sem dispositi- 
vos virais como o copyleft, o que permite que 
lancem produtos proprietaries simultaneamen- 
te aos produtos comunitarios - de maneira que 
a colaboragao e apenas uma forma de capturar 
desenvolvimento de codigo nao remunerado. 
Se as licengas nao virais comegarem a prevale- 
cer e possivel que, a medio prazo, os codigos li- 
vres se fragmentem em produtos proprietaries 
concorrentes, como aconteceu com o Unix. 

• Como a forma de recompensa do regime priva- 
do - o assalariamento - tern prevalecido entre 
os grandes colaboradores dos principals proje- 
tos de software livre - em oposigao a uma co- 
laboragao predominantemente voluntaria no 
passado -, e possivel que a contribuigao nao 
remunerada passe pouco a pouco a ser vista 


como ingenuidade ou anacronismo ate desapa- 
recer a medio prazo (Benkler, 2006). Se a cola- 
boragao subsistisse sem a dimensao voluntaria 
das contribuigoes de individuos autonomos e 
pesquisadores, teriamos entao um curioso caso 
de colaboragao entre empresas, talvez analogo 
ao estabelecimento dos consorcios para a deter- 
minagao de padroes tecnicos. 

• Por fim, e possivel que as empresas comecem a 
utilizar estrategias mais abertas para conduzir 
os projetos colaborativos de software livre ou de 
codigo aberto de acordo com os seus interes- 
ses - hoje elas apenas contratam bons progra- 
madores que atuam “espontaneamente” como 
lideres mais ou menos formais dos projetos - e 
passem a utilizar estrategias para valorizar seus 
servi^os que e onde esta a sua fonte principal 
de faturamento. Isso poderia acontecer, por 
exemplo, na produ^ao de pouca documenta^ao 
ou documentagao de baixa qualidade, de forma 
a tornar mais necessaria a prestagao de servi$o. 
Observa-se ainda, de maneira mais nitida, na 
enfase dada a produgao de desenvolvimento 
para servidores corporativos em detrimento de 
desenvolvimento para os desktops, cujo merca- 
do de servi^os e ainda pouco desenvolvido na 
avaliagao das empresas. 25 

Embora essas sejam tendencias reais observaveis, 
ha tambem muita resistencia por parte dos progra- 
madores que valorizam sua forma tradicional de or- 
ganizagao do trabalho. O que podemos vir a assistir, 
nos proximos anos, talvez nao deva ser caracterizado 
propriamente como uma “degradagao do regime pu- 
blico”, mas como a constituigao de um novo regi- 
me que misture caracteristicas do regime publico e 
privado e que, provavelmente, encontre uma contra- 
partida nas modificagoes que o regime publico esta 
sofrendo em universidades e institutos publicos de 
pesquisa que estao incorporando tragos do regime 
de produgao e organizagao de empresas (Kleinman 
e Valias, 2001, 2008). Esse novo regime podera fa- 
zer convergir a organizagao produtiva das universi- 
dades e das empresas - em particular das empresas 
de tecnologia ou daquelas que concentram pesqui- 
sa e desenvolvimento sem contrapartida industrial 
significativa -, tornando obsoletos, na sua forma 


98 


REVISTA BRASILEIRA DE CIENCIAS SOCIAIS - VOL. 26 N° 76 


tradicional, os valores publicos da colaboragao e do 
desinteresse, os quais precisarao ser retomados em 
novas bases. Mas esses desdobramentos estao, para 
os analistas, ainda no registro da especulagao. O que 
talvez nao seja mera especulaqao e a constataqao de 
que, no encontro entre o regime publico/cientffico 
e o regime privado/empresarial, as pradcas colabo- 
rativas dos programadores de software podem estar 
adquirindo novos sentidos que, por vezes, contradi- 
zem seu significado original. Onde ha condnuaqao 
e expansao de pradcas colaboradvas, podem estar 
emergindo, na verdade, novos padroes de competi- 
qao e mercandlizagao. 

Notas 

1 A literatura sobre o tema nao usa, necessariamente, o 
termo regime, mas nogoes semelhantes que nos permi- 
tem trafar paralelos e associates. Henkel (2006), por 
exemplo, trabalha com a ideia de tipos de inovagao (ino- 
vagao classica ou fechada em contraposigao a inovagao 
coletiva ou aberta). Gambardella e Hall (2006) falam 
em modos de pesquisa (pesquisa de dominio publico 
em contraposigao a pesquisa proprietaria). Laat (2005) 
fala em regimes de propriedade (copyright X copyleft), 
Bonaccorsi e Rossi (2003), em processos de inovagao; 
Osterloch e Rota (2007), em modelos de inovagao. To- 
dos eles, porem, aceitam a ideia de que existem duas 
“formas” de desenvolver software, as quais correspon- 
dent determinadas caracteristicas. 

2 Segundo Campbell- Kell e Aspray (1996), no comego 
da decada de 1990 havia, no maximo, cem programa- 
dores de computador nos Estados Unidos. 

3 Eram elas a North American Aviation, a Douglas 
Aircraft Company, a IBM, a Ramo-Woolridge, e a 
RAND Corporation. 

4 Um sistema operacional e, basicamente, o conj un- 
to de programas que fazem um aparelho eletronico 
qualquer - como um computador, um celular etc. - 
funcionar. Em suma, e o software que viabiliza o fun- 
cionamento do Hardware. Ele se constitui, portanto, 
em um elemento fundamental do funcionamento de 
um computador. 

5 “Para que a colaboragao exista, precisa haver uma 
cultura de colaboragao. Antes do PACT essa cultura 
simplesmente nao existia” (Kim, 2005). 

6 Um consent decree - em portugues, compromisso de 
cessagao ou decreto de consentimento - e um acordo 


judicial feito pelas partes de um processo antes do jul- 
gamento judicial. 

7 Segundo Weber, Thompson desenvolveu a primeira 
versao do Kernel do Unix durante as quatro semanas 
de suas ferias de verao do Bell Labs em 1969. O Unix, 
nessa epoca, chamava-se ainda Unics, numa mengao 
explicita ao Multics (Weber, 2004, p. 25). 

8 IV Simposio Sobre Principios de Sistemas Operacionais. 

9 Kernel (em portugues, cerne ou nucleo) e a parte mais 
importante de um sistema operacional, porque possi- 
bilita a comunicagao dos componentes de hardware (a 
parte ffsica da maquina) e o software (o sistema logico 
ou programa). 

10 A unica exigencia era que nos licenciamentos futuros 
e na divulgagao do software fossem dados creditos a 
Universidade da California. Mesmo essa “clausula de 
propaganda”, como era chamada, foi retirada, poste- 
riormente, das licengas BSD. 

11 Disponfvel em <http://www.freebsd.org/copyright/ 
license.html>. 

12 O projeto Networking Release 1 foi o primeiro a en- 
volver uma comunidade de programadores/usuarios 
de software num projeto de desenvolvimento ampla- 
mente centrado em contribuigoes via Internet. Esse 
processo formalizou, pela primeira vez, um modelo 
de coordenagao do trabalho de desenvolvimento de 
software que viria a se consolidar na decada de 1990, 
qual seja, a de um desenvolvimento distribui'do e co- 
ordenado pela rede, em que cada colaborador volun- 
tario recebe um reconhecimento nominal quando da 
divulga^ao do projeto concluldo. 

1 3 Eric Raymond afirma que a escolha de criar um siste- 
ma compatfvel com Unix era reveladora de uma tra- 
difao mais antiga de colabora 5 ao: “A escolha de RMS 
[Richard Matthew Stallman] de modelar o sistema 
operacional GNU sobre o Unix reflete, num nfvel 
tecnico, o fato cultural de uma comunidade [de cola- 
borajao] pre-existente” (Raymond, 2003). 

14 Na verdade, a expressao ja havia sido utilizada antes, 
em 1965, por Gregory Hill e Kerry Thornley em 
Principia Dischordia, obra na qual Hopkins provavel- 
mente se inspirou. Ver Grassmuck (s.d). 

15 A difereni^a entre ciencia e tecnologia nao sera discu- 
tida em detalhe aqui, porque nao e fundamental para 
o problema que apresentamos. Ver, nesse sentido, 
Cupani (2006) e Forman (2007). 

16 Owen-Smith, em especial, destaca que — desde que a 
Segunda Guerra Mundial, quando a ciencia deixou 
paulatinamente de ser vista como um instrumento de 


ACTIVIST-DRIVEN INNOVATION 


99 


capacita^ao belica e passou a representar uma ferra- 
menta para o aumento da competitividade da econo- 
mia nacional, a atividade cientifica passou a ser vista 
como um trabalho; dessa perspectiva, ainda, as normas 
cienrificas permitem uma maior eficiencia da gestao das 
atividades cienrificas (Owen-Smith, 2001, p. 427). 

17 Segundo Raymond, “Existe uma meritocracia mui- 
to estrita (o melhor artesao ganha) e existe um forte 
ethos de que a qualidade poderia (na verdade, deveria) 
falar por si mesma” (2000, p. 12). 

18 Esse processo tornou-se mais complexo no caso da 
ciencia por conta tanto da fragmenta^ao das praticas 
e tradi^oes de pesquisa como da institucionalizajao 
da avalia^ao meritocratica, que favorece a ado^ao de 
criterios estritamente quantitativos, o que, as vezes, 
conflita com formas mais tradicionais de avaliajao e 
hierarquiza^ao. No caso do software livre, no entanto, 
essa descrRao ainda e bastante procedente. 

19 Latour e Woolgar (1979), por exemplo, destacam o ca- 
rater de negociajao e, portanto, de constru^ao social 
por tras da consolida 5 ao de verdades cienrificas, o que 
coloca em xeque, de certa forma, o carater estritamente 
racional da ciencia. Ja Bourdieu, discordando explicita- 
mente dos primeiros, aponta na dire 5 ao contraria. Para 
ele, “o fato de os produtores tenderem a ter como clien- 
tes apenas os seus adversaries mais rigorosos, os mais 
competentes e criticos, portanto os mais inclinados e os 
mais aptos a validar a sua critica, e, para mim, o ponto 
arquimediano em que nos podemos basear para expli- 
car cientificamente a razao da cientifica” (Bourdieu, 
2004, p. 78). Assim como Bourdieu, muitos entendem 
que e a publicafao dos resultados que constitui a garan- 
tia da racionalidade cientifica. 

20 Richard Nelson e um dos autores mais sensiveis a re- 
lajao entre eficiencia e abertura da ciencia. Segundo 
ele: “Todos os cientistas sao livres para testar os resul- 
tados dos seus colegas e acha-los validos ou nao, e para 
construir sobre esses resultados os seus proprios traba- 
lhos. Porque os resultados das pesquisas cienrificas sao 
deixados no dominio publico para teste e desenvolvi- 
mentos futuros, e que o conjunto do conhecimento 
cientifico aceito e confiavel [...] e o conhecimento 
cientifico e cumulativo. Essas sao as razoes basicas do 
porque de a empresa cientifica ter sido tao eficiente 
como engrenagem de descobertas” (2004, p. 456). 

21 A licen^a do httpd nao era livre nos termos da Free 
Software Foundation. Ela permitia a distribui^ao e a 
modifica^ao do codigo, mas restringia a redistribuRao 
comercial. Trata-se de uma opjao semelhante aquela 
primeira adotada por Linus Torvalds — o que demons- 


tra, alias, como Stallman, por meio da GPL, modifi- 
cou o entendimento intuitivo que se tinha de licen^as 
“livres”. Ver <http://hoohoo.ncsa.uiuc.edu/docs/CO- 
PYRIGHT.htmb. 

22 Dispom'vel em <http://web.archive.org/web/1996l0 
28122409/www.apache.org/docs/FAQ.html>. 

23 Dispom'vel em <http://httpd.apache.org/ABOUT_ 
APACHE. html>. 

24 “Os ambientes de mercado oferecem uma defini^ao de 
sucesso para as firmas, e essa defini^ao esta muito pro- 
xima a habilidade delas de sobreviver e crescer. Padroes 
diferenciais de sobrevivencia e crescimento numa po- 
pula^ao de firmas podem produzir mudanqas nos agre- 
gados economicos que caracterizam aquela popula^ao, 
ainda que as caracteristicas correspondentes das firmas 
sejam constantes” (Nelson, 2005. p. 26). 

25 E o caso, por exemplo do ex-programador do kernel 
do Linux, Con Kolivas, que ao sair da equipe de de- 
senvolvimento afirmou que a baixa performance dos 
desktops deve-se ao fato de estarem repletos de “por- 
carias” empresariais (Kolivas, 2007). 
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ACTIVIST-DRIVEN INNOVATION: 
UMA HISTORIA INTERPRETATIVA 
DO SOFTWARE LIVRE 

Maria Caramez Carlotto 
e Pablo Ortellado 

Palavras-chave: Inova^ao; Propriedade 
intelectual; Software livre; Regimes de 
produfao de conhecimento. 

A compreensao de que existem dois regi- 
mes distintos para a produ^ao de software 
e cada vez mais comum na literatura so- 
bre o tema. O que nao e tao comum, e se 
configura, portanto, como a contribuigao 
mais original deste artigo e, de um lado, a 
abordagem historica da configuratjao des- 
ses dois regimes e, de outro, a analise dos 
fatores que determinam o sucesso tecnico 
e “comercial” de um regime em detri- 
mento do outro. Assim, trabalhamos com 
duas hipoteses complementares: a primei- 
ra, de que o desenvolvimento do software 
livre pertence historicamente ao regime 
publico/ cientifico de produfao do conhe- 
cimento, ou seja, o software livre mimeti- 
za a organizaqao da comunidade cientifica 
porque tem nela as suas raizes historicas; 
e a segunda de que, em uma “competiqao 
de mercado”, o regime publico/cientifi- 
co se mostrou mais eficiente e, por isso, 
obrigou as empresas que trabalhavam no 
regime privado/empresarial a adotar o sof- 
tware livre ou de codigo aberto. 


ACTIVIST-DRIVEN INNOVATION: 
AN INTERPRETIVE HISTORY OF 
FREE SOFTWARE 

Maria Caramez Carlotto and Pablo 
Ortellado 

Keywords: Innovation; Intellectual prop- 
erty; Free software; Knowledge produc- 
tion regimes. 

The understanding that there are two 
distinct regimes for the production of 
software is increasingly common in lit- 
erature. What is not so common, and is 
therefore the most original contribution 
of this paper is, on the one hand, the 
historical approach to the configuration 
of those regimes and, on the other hand, 
the analysis of the factors determining 
the technical and commercial success of 
one regime over the other. Furthermore, 
we have worked with two additional hy- 
potheses: first, that the development of 
free software historically belongs to the 
public/scientific knowledge production 
regime — i.e., free software mimicking 
the organization of the scientific commu- 
nity because it has its historical roots in 
it; and secondly, that in a “market com- 
petition” environment the public and 
scientific regime has proven more effi- 
cient and has therefore forced companies 
working in the private/business regime to 
adopt free or open source software. 


ACTIVIST-DRIVEN INNOVATION. 
UNE HISTOIRE INTERPRETATIVE 
DU LOGICIEL LIBRE 

Maria Caramez Carlotto et Pablo 
Ortellado 

Mots-cles: Innovation; Propriete intel- 
lectuelle; Logiciel libre; Regimes de pro- 
duction du savoir. 

La comprehension de l’existence de deux 
systemes distincts pour la production 
de logiciels est de plus en plus courante 
dans la litterature sur le sujet. Ce qui 
n’est pas tres usuel, et se configure, par 
consequent, comme etant la contribu- 
tion la plus originale de cet article est, 
d’une part, l’approche historique de 
la configuration de ces deux systemes 
et, d’autre part, l’analyse des facteurs 
qui determinent le succes technique et 
“commercial” d’un systeme au detriment 
d un autre. Nous avons, ainsi, travaille 
avec deux hypotheses complementaires: 
la premiere, celle selon laquelle le deve- 
loppement de logiciels fibres appartient 
historiquement au regime publique/ 
scientifique de production du savoir, 
c’est-a-dire, le logiciel fibre reproduit 
l’organisation de la communaute scienti- 
fique, car il incorpore des racines histo- 
riques de cette communaute; la seconde 
s’appuie sur le fait que dans une “concur- 
rence du marche”, le systeme public et 
scientifique s’ est avere plus efficace et a 
done force les entreprises qui travaillaient 
sous le regime prive d’adopter le logiciel 
fibre ou open source. 


